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

Groups > linux.kernel > #1474962 > unrolled thread

Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

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] Fix chance of sign extension to nsec after its msb is  set during calculation. Thomas Gleixner <tglx@linutronix.de> - 2016-09-02 11:00 +0200
    Re: [PATCH] Fix chance of sign extension to nsec after its msb is  set during calculation. Thomas Gleixner <tglx@linutronix.de> - 2016-09-02 20:40 +0200
      Re: [PATCH] Fix chance of sign extension to nsec after its msb is  set during calculation. Thomas Gleixner <tglx@linutronix.de> - 2016-09-02 20:50 +0200
      RE: [PATCH] Fix chance of sign extension to nsec after its msb is set  during calculation. Liav Rehana <liavr@mellanox.com> - 2016-09-04 09:20 +0200
        RE: [PATCH] Fix chance of sign extension to nsec after its msb is  set during calculation. Thomas Gleixner <tglx@linutronix.de> - 2016-09-04 11:10 +0200
          RE: [PATCH] Fix chance of sign extension to nsec after its msb is  set during calculation. Thomas Gleixner <tglx@linutronix.de> - 2016-09-04 12:50 +0200
          RE: [PATCH] Fix chance of sign extension to nsec after its msb is set  during calculation. Liav Rehana <liavr@mellanox.com> - 2016-09-05 00:50 +0200
      Re: [PATCH] Fix chance of sign extension to nsec after its msb is set  during calculation. John Stultz <john.stultz@linaro.org> - 2016-09-07 05:30 +0200

#1474962 — Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Thu, 1 Sep 2016, Liav Rehana wrote:
> From: Liav Rehana <liavr@mellanox.com>
> 
> 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 <liavr@mellanox.com>
> ---
>  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.

Thanks,

	tglx

[toc] | [next] | [standalone]

#1475399

On Fri, 2 Sep 2016, Thomas Gleixner wrote:
> On Thu, 1 Sep 2016, Liav Rehana wrote:
> > From: Liav Rehana <liavr@mellanox.com>
> > 
> > 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 <liavr@mellanox.com>
> > ---
> >  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?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1475405

On Fri, 2 Sep 2016, Thomas Gleixner wrote:
> 
> As a side note. John, why is that stuff unsigned at all? Shouldn't we use

s/unsigned/signed/

> u64 for all of this?
> 
> Thanks,
> 
> 	tglx
> 

[toc] | [prev] | [next] | [standalone]

#1475875 — RE: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

Hi Thomas,

The root of the problem is that in case the multiplication of delta and tkr->mult in the line that I've changed
is too big that the MSB of the result is set, then the shift will cause an unwanted sign extension.

That sign extension will be avoided completely if the variable nsec was unsigned (u64 instead of s64), so I
think the correct solution for this is to change the type of nsec to u64.

Do you agree ?
If not, what is the reason for it being of s64 type in the first place ?
Is there any place where we want the nsec variable to contain a negative value ?
Moreover, how can we cope with the sign extension problems in this case ?

Thanks,
Liav.

-----Original Message-----
From: Thomas Gleixner [mailto:tglx@linutronix.de] 
Sent: Friday, September 02, 2016 9:31 PM
To: Liav Rehana <liavr@mellanox.com>
Cc: linux-kernel@vger.kernel.org; john.stultz@linaro.org; Noam Camus <noamca@mellanox.com>; Elad Kanfi <eladkan@mellanox.com>
Subject: Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Fri, 2 Sep 2016, Thomas Gleixner wrote:
> On Thu, 1 Sep 2016, Liav Rehana wrote:
> > From: Liav Rehana <liavr@mellanox.com>
> > 
> > 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 <liavr@mellanox.com>
> > ---
> >  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?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1475894

On Sun, 4 Sep 2016, Liav Rehana wrote:

Please do not top post and trim your reply.

> The root of the problem is that in case the multiplication of delta and
> tkr->mult in the line that I've changed is too big that the MSB of the
> result is set, then the shift will cause an unwanted sign extension.

I completely understand that, but as I said before:

> > 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.

> That sign extension will be avoided completely if the variable nsec was
> unsigned (u64 instead of s64), so I think the correct solution for this
> is to change the type of nsec to u64.

That's a different story and its not a solution for the general problem of

       delta * mult >= (1 << 31) or delta * mult >= (1 << 32)

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1475908

On Sun, 4 Sep 2016, Liav Rehana wrote:
> >> The root of the problem is that in case the multiplication of delta 
> >> and
> >> tkr->mult in the line that I've changed is too big that the MSB of the
> >> result is set, then the shift will cause an unwanted sign extension.
> 
> > I completely understand that, but as I said before:
> 
> > > > 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.
> 
> > > That sign extension will be avoided completely if the variable nsec 
> > > was unsigned (u64 instead of s64), so I think the correct solution for 
> > > this is to change the type of nsec to u64.
> 
> > That's a different story and its not a solution for the general problem of
> 
> >        delta * mult >= (1 << 31) or delta * mult >= (1 << 32)
> 
> The case that delta * mult >= 1 << 31 is not a problem by itself, but it causes
> an unwanted sign extension since the type of nsec is signed. That sign
> extension is what causes the loop to take too long, and not the overflow.
> I understand that the typecast is not a general solution, so as I've said, I
> think that changing the type of nsec to u64 instead of s64 will be a good and
> general solution, as it will indeed solve the problem of the unwanted sign
> extension.
> 
> To summarize: a sign extension occurs if the nsec variable is signed, and so
> I ask if you think it will be a good solution to change its type to unsigned.

Do you actually read what I write? I asked John before:

> John, why is that stuff signed at all? Shouldn't we use u64 for all of this?

So to summarize: 

   - Yes, we can use u64 if there is nothing which I missed, but John will
     have the last word on this

   - No, making it u64 does not solve the general problem. It just papers
     over the problem you observe. And we don't add 'paper over' fixes,
     period.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1476051 — RE: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

>> The root of the problem is that in case the multiplication of delta 
>> and
>> tkr->mult in the line that I've changed is too big that the MSB of the
>> result is set, then the shift will cause an unwanted sign extension.

> I completely understand that, but as I said before:

> > > 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.

> > That sign extension will be avoided completely if the variable nsec 
> > was unsigned (u64 instead of s64), so I think the correct solution for 
> > this is to change the type of nsec to u64.

> That's a different story and its not a solution for the general problem of

>        delta * mult >= (1 << 31) or delta * mult >= (1 << 32)

The case that delta * mult >= 1 << 31 is not a problem by itself, but it causes
an unwanted sign extension since the type of nsec is signed. That sign
extension is what causes the loop to take too long, and not the overflow.
I understand that the typecast is not a general solution, so as I've said, I
think that changing the type of nsec to u64 instead of s64 will be a good and
general solution, as it will indeed solve the problem of the unwanted sign
extension.

To summarize: a sign extension occurs if the nsec variable is signed, and so
I ask if you think it will be a good solution to change its type to unsigned.

Thanks,
	Liav.

[toc] | [prev] | [next] | [standalone]

#1477949 — Re: [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation.

On Fri, Sep 2, 2016 at 11:30 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 2 Sep 2016, Thomas Gleixner wrote:
>> On Thu, 1 Sep 2016, Liav Rehana wrote:
>> > From: Liav Rehana <liavr@mellanox.com>
>> >
>> > 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 <liavr@mellanox.com>
>> > ---
>> >  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.

thanks
-john

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web