lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 Jun 2022 09:58:47 +0200
From:   Geert Uytterhoeven <>
To:     Linus Torvalds <>
Cc:     Matthew Wilcox <>,
        "Jason A. Donenfeld" <>,
        Linux-MM <>,
        linux-xfs <>,,
        Linux Kernel Mailing List <>,
        Uladzislau Rezki <>,
        Kees Cook <>,
        Greg Kroah-Hartman <>,
        Joe Perches <>
Subject: Re: [PATCH] usercopy: use unsigned long instead of uintptr_t

Hi Linus,

On Thu, Jun 16, 2022 at 9:15 PM Linus Torvalds
<> wrote:
> On Thu, Jun 16, 2022 at 9:56 AM Linus Torvalds
> <> wrote:
> > Out bitmaps and bit fields are also all about "long" - again, entirely
> > unrelated to pointers.
> That, btw, has probably been a mistake. It's entirely historical. We
> would have been better off had our bitmap types been defined in terms
> of 32-bit chunks, because now we have the odd situation that 32-bit
> and 64-bit architectures get very different sizes for some flag
> fields.
> It does have a technical reason: it's often better to traverse bitmaps
> in maximally sized chunks (ie scanning for bits set or clear), and in
> that sense defining bitmaps to always act as arrays of "long" has been
> a good thing.

Indeed, as long is the native word size, it's assumed to be the best,
performance-wise.  For bitmaps, the actual underlying unit doesn't
matter that much to the user, as bitmaps can span multiple words.
For bit fields, you're indeed stuck with the 32-vs-64 bit difference.

> But it then causes pointless problems when people can't really rely on
> more than 32 bits for atomic bit operations, and on 64-bit
> architectures we unnecessarily use "long" and waste the upper bits.

Well, atomic works up to native word size, i.e. long.

> It's not entirely unlikely that we'll end up with a situation where we
> do have access to 128-bit operations (because ALU and register width
> is relatively "cheap", and it helps some loads - extended precision
> arithmetic, crypto, integer vectors), but the address space will be
> 64-bit (because big pointers are bad for memory and cache use).
> In that situation, we'd probably just see "long long" being 128-bit
> ("I32LP64LL128").

Regardless of the address space decision (we do have size_t and the
dreaded uintptr_t to cater for that), keeping long at 64-bit would
break the "long is the native word size" assumption (as used in lots
of places, e.g. for syscalls).



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists