linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Florian La Roche <florian.laroche@googlemail.com>
Cc: linux-kernel@vger.kernel.org, Crt Mori <cmo@melexis.com>,
	Joe Perches <joe@perches.com>,
	Davidlohr Bueso <dave@stgolabs.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: fix int_sqrt() for very large numbers
Date: Sun, 20 Jan 2019 00:01:40 +0000	[thread overview]
Message-ID: <20190120000138.GI26876@brain-police> (raw)
In-Reply-To: <20190119151450.26879-1-Florian.LaRoche@googlemail.com>

On Sat, Jan 19, 2019 at 04:14:50PM +0100, Florian La Roche wrote:
> If an input number x for int_sqrt() has the highest bit set, then
> __ffs(x) is 64. (1UL << 64) is an overflow and breaks the algorithm.

This is confusing, because the patch doesn't go near an __ffs().

> Just subtracting 1 is an even better guess for the initial
> value of m and that's what also used to be done in earlier
> versions of this code.
> 
> best regards,
> 
> Florian La Roche
> 
> Signed-off-by: Florian La Roche <Florian.LaRoche@googlemail.com>
> ---
>  lib/int_sqrt.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/int_sqrt.c b/lib/int_sqrt.c
> index 14436f4ca6bd..ea00e84dc272 100644
> --- a/lib/int_sqrt.c
> +++ b/lib/int_sqrt.c
> @@ -23,7 +23,7 @@ unsigned long int_sqrt(unsigned long x)
>  	if (x <= 1)
>  		return x;
>  
> -	m = 1UL << (__fls(x) & ~1UL);
> +	m = 1UL << ((__fls(x) - 1) & ~1UL);

I think this one is fine, because __fls() gives you back 0-63 (or
undefined, but the previous <= 1 check handles that case).

>  	while (m != 0) {
>  		b = y + m;
>  		y >>= 1;
> @@ -52,7 +52,7 @@ u32 int_sqrt64(u64 x)
>  	if (x <= ULONG_MAX)
>  		return int_sqrt((unsigned long) x);
>  
> -	m = 1ULL << (fls64(x) & ~1ULL);
> +	m = 1ULL << ((fls64(x) - 1) & ~1ULL);

This just looks like a copy-paste error because there isn't an __fls64().
But I think your suggestion here is ok, given the previous check against
ULONG_MAX.

Will

  reply	other threads:[~2019-01-20  0:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-19 15:14 fix int_sqrt() for very large numbers Florian La Roche
2019-01-20  0:01 ` Will Deacon [this message]
2019-01-20  3:48   ` Linus Torvalds
2019-01-20  5:03     ` Florian La Roche
2019-01-20  5:11       ` Linus Torvalds
2019-01-20  8:31     ` Crt Mori
2019-01-20  9:29       ` Crt Mori
2019-01-20 10:00         ` Linus Torvalds
2019-01-21  0:20 ` Linus Torvalds
2019-01-21 20:25   ` Crt Mori
2019-02-02  6:11 ` [LKP] 32bd07585d: kernel_selftests.lib.prime_numbers.sh.fail kernel test robot
2019-02-02 13:10   ` Florian La Roche

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=20190120000138.GI26876@brain-police \
    --to=will.deacon@arm.com \
    --cc=cmo@melexis.com \
    --cc=dave@stgolabs.net \
    --cc=florian.laroche@googlemail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).