linux-kernel - Re: [PATCH v14 2/3] rust: io: mem: add a generic iomem abstraction

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: <DBDU05DKSHHB.SHRSPEM7J6MQ@kernel.org>
Date: Thu, 17 Jul 2025 00:26:57 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Daniel Almeida" <daniel.almeida@...labora.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Alex Gaynor"
 <alex.gaynor@...il.com>, "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>, "Alice Ryhl" <aliceryhl@...gle.com>,
 "Trevor Gross" <tmgross@...ch.edu>, "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
 <linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v14 2/3] rust: io: mem: add a generic iomem abstraction

On Wed Jul 16, 2025 at 11:52 PM CEST, Daniel Almeida wrote:
> Hi,
>
> […]
>
>> +
>> +/// An exclusive memory-mapped IO region.
>> +///
>> +/// # Invariants
>> +///
>> +/// - [`ExclusiveIoMem`] has exclusive access to the underlying [`IoMem`].
>> +pub struct ExclusiveIoMem<const SIZE: usize> {
>> +    /// The underlying `IoMem` instance.
>> +    iomem: IoMem<SIZE>,
>> +
>> +    /// The region abstraction. This represents exclusive access to the
>> +    /// range represented by the underlying `iomem`.
>> +    ///
>> +    /// This field is needed for ownership of the region.
>> +    _region: Region,
>> +}
>> +
>> +impl<const SIZE: usize> ExclusiveIoMem<SIZE> {
>> +    /// Creates a new `ExclusiveIoMem` instance.
>> +    fn ioremap(resource: &Resource) -> Result<Self> {
>> +        let start = resource.start();
>> +        let size = resource.size();
>> +        let name = resource.name().ok_or(EINVAL)?;
>
> Note the change above. If there’s no name, we fail.
>
> I just noticed that this may not be the right approach, but OTOH we should note that
> “not having a name” is apparently considered a bug in the C code under some
> circumstances:

If we'd consider it to be a bug strictly speaking we should not make it an
Option and fix the bugs instead.

However, I don't think this is a bug, there are plenty of "constructor" macros
that create resource structures with a NULL pointer for the name field
(DEFINE_RES_IRQ(),  DEFINE_RES_REG(), etc.).

Besides that, also the C APIs do the name check, __devm_ioremap_resource() [1]
is such an example.

Busses often assign the corresponding device name later on, but I wouldn't bet
on this to be a hard rule and nothing this abstraction can rely on anyways.

I think we should just pick a fallback string.

[1] https://elixir.bootlin.com/linux/v6.15.6/source/lib/devres.c#L144