linux-kernel - Re: [PATCH v2 0/4] Rust: Fix typedefs for resource_size_t and phys_addr

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: <CANiq72maV_j1uV=2nPGbTgRabnk8cpc7TNN_FQ+ou52OpZ=k6Q@mail.gmail.com>
Date: Wed, 12 Nov 2025 11:12:32 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Daniel Almeida <daniel.almeida@...labora.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, Abdiel Janulgue <abdiel.janulgue@...il.com>, 
	Robin Murphy <robin.murphy@....com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, 
	"Rafael J. Wysocki" <rafael@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v2 0/4] Rust: Fix typedefs for resource_size_t and phys_addr_t

On Wed, Nov 12, 2025 at 10:49 AM Alice Ryhl <aliceryhl@...gle.com> wrote:
>
> This changes ResourceSize to use the resource_size_t typedef (currently
> ResourceSize is defined as phys_addr_t), and moves ResourceSize to
> kernel::io and defines PhysAddr next to it. Any usage of ResourceSize or
> bindings::phys_addr_t that references a physical address is updated to
> use the new PhysAddr typedef.

Should we have these as actual types instead of aliases? i.e. same
discussion as for `Offset`.

If there is a change of these getting mixed up, then I think we should
just pay that price (not necessarily now, of course).

> I included some cc stable annotations because I think it is useful to
> backport this to v6.18. This is to make backporting drivers to the 6.18
> LTS easier as we will not have to worry about changing imports when
> backporting.

For context, will those drivers be backported upstream too?

i.e. we have sometimes backported bits to simplify further backporting
elsewhere, which is fine and up to the stable team of course, but I am
not sure if using Option 1 (i.e. the Cc tag) may be a bit confusing in
the log, i.e. Option 2 or 3 offer a better chance to give a reason.

Thanks!

Cheers,
Miguel