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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <DE8PBRC48D14.IX6FUPOLLVHR@kernel.org>
Date: Sat, 15 Nov 2025 07:31:37 +1100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Zhi Wang" <zhiw@...dia.com>
Cc: "Alice Ryhl" <aliceryhl@...gle.com>, <rust-for-linux@...r.kernel.org>,
 <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.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>, <jhubbard@...dia.com>,
 <zhiwang@...nel.org>
Subject: Re: [PATCH v6 RESEND 4/7] rust: io: factor common I/O helpers into
 Io trait

On Sat Nov 15, 2025 at 4:27 AM AEDT, Zhi Wang wrote:
> On Fri, 14 Nov 2025 12:58:31 +0000
> Alice Ryhl <aliceryhl@...gle.com> 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?

Yeah, though I did like that with this split we can enforce one or the other.

E.g. in the case of the PCI configuration space we can always assert the
expected size at compile time and drivers should not have to deal with runtime
offsets either.

Hence, with this split we can avoid that drivers implement unnecessary runtime
checks.

Either is fine with me though.

>> And why are these separate traits at all? Why not support both
>> compile-time and runtime-checked IO always?
>>
>
> Hi Alice:
>
> Thanks for comments. I did have a version that PCI configuration space
> only have fallible accessors because I thought the device can be
> unplugged or a VF might fail its FLR and get unresponsive, so the driver
> may need to check the return all the time. And Danilo's comments were
> let's have the infallible accessors for PCI configuration space and add
> them later if some driver needs it. [1]

Yeah, that's the same with MMIO accesses as well, yet we don't check all the
time. Actually, when a device falls from the bus, the error state is not
available immediately either and hence drivers have to be robust enough to deal
with it anyway.

Adding in that a driver is also unbound as soon as the device falling from the
bus is detected, there is not much value in those checks.