linux-kernel - Re: [PATCH v6 RESEND 4/7] rust: io: factor common I/O helpers into Io trait

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: <7b30a8a5-ec0b-4cc6-9e9a-2ff2b42ca3cf@nvidia.com>
Date: Mon, 17 Nov 2025 14:44:05 -0800
From: John Hubbard <jhubbard@...dia.com>
To: Alice Ryhl <aliceryhl@...gle.com>, Zhi Wang <zhiw@...dia.com>
Cc: rust-for-linux@...r.kernel.org, linux-pci@...r.kernel.org,
 linux-kernel@...r.kernel.org, dakr@...nel.org, bhelgaas@...gle.com,
 kwilczynski@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com,
 boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
 lossin@...nel.org, a.hindborg@...nel.org, tmgross@...ch.edu,
 markus.probst@...teo.de, helgaas@...nel.org, cjia@...dia.com,
 smitra@...dia.com, ankita@...dia.com, aniketa@...dia.com,
 kwankhede@...dia.com, targupta@...dia.com, acourbot@...dia.com,
 joelagnelf@...dia.com, zhiwang@...nel.org
Subject: Re: [PATCH v6 RESEND 4/7] rust: io: factor common I/O helpers into Io
 trait

On 11/14/25 4:58 AM, Alice Ryhl wrote:
> On Mon, Nov 10, 2025 at 10:41:16PM +0200, Zhi Wang wrote:
...
> This defines three traits:
> 
> * Io
> * IoInfallible: Io
> * IoFallible: Io
> 
> This particular split says that there are going to be cases where we
> implement IoInfallible only, cases where we implement IoFallible only,
> and maybe cases where we implement both.
> 
> And the distiction between them is whether the bounds check is runtime
> or compile-time.
> 
> But this doesn't make much sense to me. Surely any Io resource that can
> provide compile-time checked io can also provide runtime-checked io, so
> maybe IoFallible should extend IoInfallible?

IO is generally something that can fail, so this whole idea of infallible
IO is making me uneasy.

I understand that we're trying to wrap it up into a bound device, but
bound devices are all about whether or not the driver lifetime is OK,
not so much about IO.

For PCIe, it is still possible for the device to fall off of the bus, and 
in that case you'll usually see 0xFFFF_FFFF returned from PCIe reads. The
Open RM driver has sprinkled around checks for this value (not fun, I
know), and Danilo hinted elsewhere that bound-ness requires not getting
these, so maybe that suffices. But it means that Rust will be "interesting"
here, because falling off the bus means that there will be a time window in
which the IO is, in fact, fallible.

Other IO subsystems can also get IO errors, too.

I wonder if we should just provide IoFallible? (It could check for the
0xFFFF_FFFF case, for example, which is helpful to simplify the caller.)

Again, it feels *really* odd to claim infallibility on something that,
almost (but not quite) by it's very nature is going to generate errors
at times.

> 
> And why are these separate traits at all? Why not support both
> compile-time and runtime-checked IO always?
> 
> I noticed also that the trait does not have methods for 64-bit writes,
> and that these are left as inherent methods on Mmio.
> 
> The traits that would make sense to me are these:
> 
> * Io
> * Io64: Io
> 
> where Io provides everything the three traits you have now provides, and
> Io64 provides the 64-bit operations. That way, everything needs to
> support operations of various sizes with both compile-time and
> runtime-checked bounds, but types may opt-in to providing 64-bit ops.
> 
> Thoughts?
> 
> Alice

thanks,
-- 
John Hubbard