linux-kernel - Re: [GIT PULL] bitmap for 6.18

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wib1_c6-MaJz+5Y_UOgyCF8+OCYKx2gnzHRCo3XaRNa4Q@mail.gmail.com>
Date: Thu, 2 Oct 2025 14:09:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Yury Norov <yury.norov@...il.com>, linux-kernel@...r.kernel.org, 
	NVIDIA <YuryNorovyury.norov@...il.com>, Alice Ryhl <aliceryhl@...gle.com>, 
	Burak Emir <bqe@...gle.com>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
	Jakub Kicinski <kuba@...nel.org>, Heiko Stuebner <heiko@...ech.de>
Subject: Re: [GIT PULL] bitmap for 6.18

On Thu, 2 Oct 2025 at 13:32, Nicolas Frattaroli
<nicolas.frattaroli@...labora.com> wrote:
>
> On Thursday, 2 October 2025 18:46:01 Central European Summer Time Linus Torvalds wrote:
> > See commit 10ef6b0dffe4 ("bitops: Introduce a more generic BITMASK
> > macro"), and notice how ALMOST ALL use cases were switched around to
> > the illogical "high,low" format by that introductory phase.
> >
> > And yes, I understand why that person did it: many datasheets show
> > bits in a register graphically, and then you see that "high .. low"
> > thing in a rectangle that describes the register, and that ordering
> > them makes 100% sense IN THAT CONTEXT.
>
> Hi, that person here.

With "that person" I was actually thinking of Gong Chen and that
original commit 10ef6b0dffe4 from 2013.

That's the one that introduced the high,low ordering - the code it
replaced actually used low-high in the EDAC driver (and high-low in
the SIS driver).

So that's the commit that started using high/low "officially".

> My datasheets indeed show registers in the probably verilog-derived
> high:low notation.

Yeah, very traditional. I suspect it predates verilog, and yes, it's
because numbers read right-to-left/

(Unless you work for IBM, in which case you start numbering bits from
the high bit)

> FWIW, I am also not a fan of GENMASK's high-to-low order. I do
> however prefer it over bare hex values

Yeah, it's not like hex values are great either, although I do end up
often reading them just about as well as bit numbering.

> > Am I the only person who would find "BITS(1,11)" to be much easier to
> > understand than "GENMASK(11,1)"?
>
> I'm with you on that, but others may disagree.

I wouldn't necessarily mind having two different ways to express bit masks.

And sometimes you don't want "beginning and end" (never mind the order
of those two) but "beginning and size".

The HI:LO format is very common in hardware documentation, but a lot
of our _software_ conventions are typically driven by packing bits
into words, and then we typically deal in "I need X bits for this".

I'm thinking things like the page flags, which are also fixed bits,
but they are fixed at compile-time depending on various
configurations, so you have things like this

   /* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */

with the different widths specified in

    include/linux/page-flags-layout.h

with fairly complicated rules. And then we shift things explicitly
with things like

   #define LRU_GEN_MASK            ((BIT(LRU_GEN_WIDTH) - 1) << LRU_GEN_PGOFF)

and we do use BIT(), but it really ends up fundamentally being "X bits
starting at Y"

           Linus