All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liav Rehana <liavr@mellanox.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"john.stultz@linaro.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.
Date: Sun, 4 Sep 2016 06:40:06 +0000	[thread overview]
Message-ID: <VI1PR0501MB2461D0661B3417EC9251703AC5E70@VI1PR0501MB2461.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1609022029571.5647@nanos>

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

  parent reply	other threads:[~2016-09-04  7:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-01 11:14 [PATCH] Fix chance of sign extension to nsec after its msb is set during calculation Liav Rehana
2016-09-02  8:49 ` Thomas Gleixner
2016-09-02 18:30   ` Thomas Gleixner
2016-09-02 18:47     ` Thomas Gleixner
2016-09-04  6:40     ` Liav Rehana [this message]
2016-09-04  9:01       ` Thomas Gleixner
2016-09-04 10:03         ` Liav Rehana
2016-09-04 10:39           ` Thomas Gleixner
2016-09-07  3:22     ` John Stultz
2016-09-11  6:31       ` Liav Rehana
2016-09-21 21:12         ` John Stultz
2016-09-21 12:52       ` Liav Rehana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR0501MB2461D0661B3417EC9251703AC5E70@VI1PR0501MB2461.eurprd05.prod.outlook.com \
    --to=liavr@mellanox.com \
    --cc=eladkan@mellanox.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=noamca@mellanox.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.