linux-kernel - Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DDC0VAHL5OCP.DROT6CPKE5H5@nvidia.com>
Date: Tue, 07 Oct 2025 19:36:21 +0900
From: "Alexandre Courbot" <acourbot@...dia.com>
To: "Yury Norov" <yury.norov@...il.com>, "Joel Fernandes"
 <joelagnelf@...dia.com>
Cc: <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>,
 <dri-devel@...ts.freedesktop.org>, <dakr@...nel.org>,
 <acourbot@...dia.com>, "Alistair Popple" <apopple@...dia.com>, "Miguel
 Ojeda" <ojeda@...nel.org>, "Alex Gaynor" <alex.gaynor@...il.com>, "Boqun
 Feng" <boqun.feng@...il.com>, "Gary Guo" <gary@...yguo.net>,
 <bjorn3_gh@...tonmail.com>, "Benno Lossin" <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "David Airlie" <airlied@...il.com>,
 "Simona Vetter" <simona@...ll.ch>, "Maarten Lankhorst"
 <maarten.lankhorst@...ux.intel.com>, "Maxime Ripard" <mripard@...nel.org>,
 "Thomas Zimmermann" <tzimmermann@...e.de>, "John Hubbard"
 <jhubbard@...dia.com>, "Timur Tabi" <ttabi@...dia.com>,
 <joel@...lfernandes.org>, "Elle Rhumsaa" <elle@...thered-steel.dev>,
 "Daniel Almeida" <daniel.almeida@...labora.com>, "Andrea Righi"
 <arighi@...dia.com>, <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to
 rust/kernel/

Hi Yuri,

On Tue Oct 7, 2025 at 7:29 AM JST, Yury Norov wrote:
<snip>
> Regardless, I don't think that this is the right path to move the
> bitfields into the core. The natural path for a feature that has
> been originally developed on driver side is to mature in there and
> get merged to core libraries after a while. Resctrl from Intel is one
> recent example.
>
> With that said, I'm OK if you move the bitfields as a whole, like you
> do in v5, and I'm also OK if you split out the part essential for nova
> and take it into the driver. In that case the bitfields will stay in 
> drivers and you'll be able to focus on the features that _you_ need,
> not on generic considerations.
>
> I'm not OK to move bitfields in their current (v6) incomplete form in
> rust/kernel. We still have no solid understanding on the API and
> implementation that we've been all agreed on.

Initially the plan was indeed to give this code some more time to mature
in nova-core before moving it out.

The reason for the early move is that we have another driver (Tyr) who
wants to start using the register macro. Without it, they would be left
with the option of either reinventing the wheel, or poking at registers
the old-fashioned way, which I think we can agree is not going to be any
safer than the current macro. :)

IIUC your remaining concern is with the possible loss of data when
setting a field that is smaller than its primitive type? That should be
addressed by [0], but as it introduces a new core feature I expect some
discussion to take place before it can be merged. In the meantime, it
would be great if we can make the register macro available.

Because letting it fully mature within nova-core also has the drawback
that we might miss the perspective of other potential users, which may
make us draw ourselves into a corner that will make the macro less
useful generally speaking. We are at a stage where we can still make
design changes if needed, but we need to hear from other users, and
these won't come as long as the macro is in nova-core.

[0] https://lore.kernel.org/rust-for-linux/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/

> On maintenance: no core functionality can be merged unmaintained - it's
> a strict rule. While in drivers, bitfields are maintained by the nova
> maintainers as part of the driver. If you make it a generic library,
> you need to define a responsible person(s) in advance. It's also a good
> practice to add a core maintainer as a reviewer or co-maintainer. Alice
> and Burak added me for bitmap/rust because I already look after bitmaps
> in C. You can do the same for bitfields, for the same reason.

We can assume maintainership of this of course, but is there a problem
if this falls under the core Rust umbrella? As this is a pretty core
functionality. Miguel and other core folks, WDYT?