>> > > During the calculation of the nsec variable, "delta * tkr->mult"
> >> > may cause overflow to the msb, if the suspended time is too long.
> >> > In that case, we need to guarantee that the variable will not go
> >> > through a sign extension during its shift, and thus it will result
> >> > in a much higher value - close to the larget value of 64 bits.
> >> > The following commit fixes this problem, which causes the following bug:
> >> > Trying to connect through ftp to the os after a long enough
> >> > suspended time will cause the nsec variable to get a much higher
> >> > value after its shift because of sign extension, and thus the loop
> >> > that follows some instructions afterwards, implemented in the
> >> > inline function __iter_div_u64_rem, will take too long.
> >> >
> >> > Signed-off-by: Liav Rehana <[email protected]>
> >> > ---
> >> > kernel/time/timekeeping.c | 2 +-
> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> >> > index 479d25c..ddf56a5 100644
> >> > --- a/kernel/time/timekeeping.c
> >> > +++ b/kernel/time/timekeeping.c
> >> > @@ -305,7 +305,7 @@ static inline s64 timekeeping_delta_to_ns(struct
> >> > tk_read_base *tkr,
> >> > s64 nsec;
> >> >
> >> > nsec = delta * tkr->mult + tkr->xtime_nsec;
> >> > - nsec >>= tkr->shift;
> >> > + nsec = ((u64) nsec) >> tkr->shift;
> >>
> >> This typecast is just a baindaid. What happens if you double the suspend
> >> time?
> >> The multiplication will simply overflow. So the proper fix is to
> >> sanity check delta and do multiple conversions if delta is big
> >> enough. Preferrably this happens somewhere at the call site and not in
> >> this hotpath function.
> >
> > As a side note. John, why is that stuff unsigned at all? Shouldn't we
> > use
> > u64 for all of this?
>
>Errrr... My memory is quite foggy here. I think we just started way back when
>with s64 to catch cases where there were negative nsec intervals. Looking
>through the git logs it seems its > been that way since the beginning of the
>generic timekeeping logic.
>
>For most cases here u64 is fine. There may be a few cases where we do have
>valid negative nanosecond intervals, but I can't think of any off the top of
>my head, and those can >probably be special cased.
In light of your comment for that issue, I would like to change the type of the
nsec variable to u64, as it will solve the sign extension problem. For that, I
intend to change the type
of that variable in the functions that define it, and in the struct that uses
it in kernel/time/timekeeping.c.
Do you think there are other references I should change. Or do you think there
is a better solution ? Please provide your opinion on this matter.
Thanks,
Liav.
