From: Linus Torvalds <torvalds@linux-foundation.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Florian La Roche <florian.laroche@googlemail.com>,
Linux List Kernel Mailing <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>
Subject: Re: fix int_sqrt() for very large numbers
Date: Sun, 20 Jan 2019 15:48:49 +1200 [thread overview]
Message-ID: <CAHk-=wjKgJ-9ypvzq+CB_NKnRk6iAqFtgVPwSH17C5RqJoYF=A@mail.gmail.com> (raw)
In-Reply-To: <20190120000138.GI26876@brain-police>
On Sun, Jan 20, 2019 at 12:01 PM Will Deacon <will.deacon@arm.com> wrote:
>
> > @@ -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.
Hmm. We probably *should* add a __fls64().
There looks to be only one user of int_sqrt64(), and that one is
confused. It does int_sqrt64() twice, but since the inner one will
reduce the range to 32 bits, the outer one is just silly.
That one user also had better not be overflowing into the high bit -
it uses "s64" as a type and does seem to use signed operatons, so high
bit set really means negative. sqrt() returning something odd for a
negative number wouldn't be all that odd in that context.
But yes, our current int_sqrt64() does seem buggy as-is, because it's
*supposed* to work on u64's, even if I don't think we really have any
users that care.
And as Will mentioned, the regular int_sqrt() looks perfectly fine,
and subtracting 1 from the __fls() return value would actually
_introduce_ a bug.
Linus
next prev parent reply other threads:[~2019-01-20 3:56 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
2019-01-20 3:48 ` Linus Torvalds [this message]
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='CAHk-=wjKgJ-9ypvzq+CB_NKnRk6iAqFtgVPwSH17C5RqJoYF=A@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--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=will.deacon@arm.com \
/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).