Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1491078 > unrolled thread

Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

Started byJohn Stultz <john.stultz@linaro.org>
First post2016-09-26 08:10 +0200
Last post2016-09-26 08:10 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in  its calculation. John Stultz <john.stultz@linaro.org> - 2016-09-26 08:10 +0200

#1491078 — Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

FromJohn Stultz <john.stultz@linaro.org>
Date2016-09-26 08:10 +0200
SubjectRe: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.
Message-ID<slxgZ-7C-5@gated-at.bofh.it>
On Sun, Sep 25, 2016 at 10:45 PM, Liav Rehana <liavr@mellanox.com> wrote:
> From: Liav Rehana <liavr@mellanox.com>
>
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a value near the maximum value of the 64-bit range. This is
> bad when it is later used in a division function, such as
> __iter_div_u64_rem, where the amount of loops it will go through to
> calculate the division will be too large.
> The following commit fixes that chance of sign extension, while
> maintaining the type of the nsec variable as signed for other
> functions that use this variable, for possible legit negative
> time intervals.

Apologies for my foggy memory here (just got off a plane).  But remind
me, is this something that you actually ran into, or is it more of
just a theoretical concern?

If it is something that you did trip on, please describe your case in
the changelog so that the proper urgency is applied when weighing if
such a commit should go into -stable.

thanks
-john

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web