linux-kernel - Re: [PATCH v4 2/3] rust: pci: impl TryFrom<&Device> for &pci::Device

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: <D8ON7WC8WMFG.2S2JRK6G9TOSL@proton.me>
Date: Mon, 24 Mar 2025 16:39:25 +0000
From: Benno Lossin <benno.lossin@...ton.me>
To: Danilo Krummrich <dakr@...nel.org>, Greg KH <gregkh@...uxfoundation.org>
Cc: bhelgaas@...gle.com, rafael@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu, linux-pci@...r.kernel.org, rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] rust: pci: impl TryFrom<&Device> for &pci::Device

On Sun Mar 23, 2025 at 11:10 PM CET, Danilo Krummrich wrote:
> On Sat, Mar 22, 2025 at 11:10:57AM +0100, Danilo Krummrich wrote:
>> On Fri, Mar 21, 2025 at 08:25:07PM -0700, Greg KH wrote:
>> > Along these lines, if you can convince me that this is something that we
>> > really should be doing, in that we should always be checking every time
>> > someone would want to call to_pci_dev(), that the return value is
>> > checked, then why don't we also do this in C if it's going to be
>> > something to assure people it is going to be correct?  I don't want to
>> > see the rust and C sides get "out of sync" here for things that can be
>> > kept in sync, as that reduces the mental load of all of us as we travers
>> > across the boundry for the next 20+ years.
>> 
>> I think in this case it is good when the C and Rust side get a bit
>> "out of sync":
>
> A bit more clarification on this:
>
> What I want to say with this is, since we can cover a lot of the common cases
> through abstractions and the type system, we're left with the not so common
> ones, where the "upcasts" are not made in the context of common and well
> established patterns, but, for instance, depend on the semantics of the driver;
> those should not be unsafe IMHO.

I don't think that we should use `TryFrom` for stuff that should only be
used seldomly. A function that we can document properly is a much better
fit, since we can point users to the "correct" API.

---
Cheers,
Benno