From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Danilo Krummrich" <dakr@kernel.org>
Cc: "Gary Guo" <gary@garyguo.net>,
lyude@redhat.com, "Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
"Zhi Wang" <zhiw@nvidia.com>,
"Eliot Courtney" <ecourtney@nvidia.com>
Subject: Re: [PATCH v2 1/6] rust: io: turn IoCapable into a functional trait
Date: Mon, 16 Feb 2026 22:27:23 +0900 [thread overview]
Message-ID: <DGGF65JPF8S6.268LR7YDPTWMQ@nvidia.com> (raw)
In-Reply-To: <DGGDHY4582D1.1GZGZ7P98OKWO@kernel.org>
On Mon Feb 16, 2026 at 9:08 PM JST, Danilo Krummrich wrote:
> On Mon Feb 16, 2026 at 12:51 PM CET, Alexandre Courbot wrote:
>> On Thu Feb 12, 2026 at 11:52 PM JST, Danilo Krummrich wrote:
>>> On Thu Feb 12, 2026 at 3:11 PM CET, Gary Guo wrote:
>>>> They can, but the `Io` trait just passes the wrong address to the `IoCapable`
>>>> trait, and nothing horrible can happen without doing things unsafely inside
>>>> `IoCapable` impl, which is controlled by the user who implements `Io`. It looks
>>>> to me that unsafe code is still needed to do bogus things.
>>>
>>> I think what you mean is that the invariant of `addr` and `maxsize` being valid
>>> is on the implementing type of `Io`, e.g. `MmioRaw` and `Mmio`. The same applies
>>> to IoKnownSize::MIN_SIZE.
>>>
>>> To me this seems like a valid way of arguing.
>>
>> But still, using only safe code an implementor of `Io` can lie about
>> this safety statement:
>>
>> // SAFETY: `address` has been validated by `io_addr`.
>> Ok(unsafe { self.io_read(address) })
>>
>> Granted, the same person will likely have written the `IoCapable`
>> implementations, but its safety requirements cannot be fulfilled unless
>> the caller also guarantees that the offsets it passes are valid, which
>> the type system alone cannot guarantee - thus the need to make `Io` and
>> `IoKnownSize` unsafe IMHO.
>
> Hm...the implementor of Io and IoCapable has to justify in the implementation of
> IoCapable, i.e. in io_read() and io_write() that the address is in fact correct.
It doesn't - here is the implementation of Io for Mmio:
impl<const SIZE: usize> Io for Mmio<SIZE> {
/// Returns the base address of this mapping.
#[inline]
fn addr(&self) -> usize {
self.0.addr()
}
/// Returns the maximum size of this mapping.
#[inline]
fn maxsize(&self) -> usize {
self.0.maxsize()
}
}
Now what prevents me from doing this:
impl<const SIZE: usize> Io for YoloMmio<SIZE> {
fn addr(&self) -> usize {
self.0.addr()
}
fn maxsize(&self) -> usize {
self.0.maxsize() + 0x10000
}
}
With that, I have allowed callers to invoke the unsafe methods of
`IoCapable` on an extra 0x10000 bytes of I/O I don't own, without any
unsafe code.
> So, considering that, it looks to me that we don't even need io_read() and
> io_write() to be unsafe in the first place?
>
> I.e. we are only passing through values in generic implementation.
Possibly? Although `io_read` and `io_write` typically call unsafe C
methods though, so they would have to always maintain *their* safety
requirements if we go that way (instead of delegating that to `Io`
through the `IoCapable` implementation's safety statement).
next prev parent reply other threads:[~2026-02-16 13:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 6:00 [PATCH v2 0/6] rust: io: turn IoCapable into a functional trait Alexandre Courbot
2026-02-06 6:00 ` [PATCH v2 1/6] " Alexandre Courbot
2026-02-06 20:29 ` lyude
2026-02-12 12:04 ` Alexandre Courbot
2026-02-12 12:23 ` Danilo Krummrich
2026-02-12 14:11 ` Gary Guo
2026-02-12 14:52 ` Danilo Krummrich
2026-02-16 11:51 ` Alexandre Courbot
2026-02-16 12:08 ` Danilo Krummrich
2026-02-16 13:27 ` Alexandre Courbot [this message]
2026-02-16 17:04 ` Danilo Krummrich
2026-02-17 1:36 ` Alexandre Courbot
2026-02-17 11:17 ` Danilo Krummrich
2026-02-06 6:00 ` [PATCH v2 2/6] rust: io: mem: use non-relaxed I/O ops in examples Alexandre Courbot
2026-02-06 6:00 ` [PATCH v2 3/6] rust: io: provide Mmio relaxed ops through a wrapper type Alexandre Courbot
2026-02-06 16:09 ` Daniel Almeida
2026-02-06 6:00 ` [PATCH v2 4/6] rust: io: remove legacy relaxed accessors of Mmio Alexandre Courbot
2026-02-06 6:00 ` [PATCH v2 5/6] rust: pci: io: remove overloaded Io methods of ConfigSpace Alexandre Courbot
2026-02-06 6:00 ` [PATCH v2 6/6] rust: io: remove overloaded Io methods of Mmio Alexandre Courbot
2026-02-06 15:02 ` [PATCH v2 0/6] rust: io: turn IoCapable into a functional trait Gary Guo
2026-02-06 19:12 ` Danilo Krummrich
2026-02-06 19:48 ` lyude
2026-02-12 12:28 ` Alexandre Courbot
2026-02-12 14:40 ` Daniel Almeida
2026-03-15 0:56 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGGF65JPF8S6.268LR7YDPTWMQ@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=driver-core@lists.linux.dev \
--cc=ecourtney@nvidia.com \
--cc=gary@garyguo.net \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.