linux-kernel - Re: [PATCH v2 1/2] rust: add abstraction for struct 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]

Date: Wed, 12 Jun 2024 17:02:52 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Danilo Krummrich <dakr@...hat.com>
Cc: Boqun Feng <boqun.feng@...il.com>, rafael@...nel.org, mcgrof@...nel.org,
	russell.h.weight@...el.com, ojeda@...nel.org, alex.gaynor@...il.com,
	wedsonaf@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
	benno.lossin@...ton.me, a.hindborg@...sung.com,
	aliceryhl@...gle.com, airlied@...il.com, fujita.tomonori@...il.com,
	pstanner@...hat.com, ajanulgu@...hat.com, lyude@...hat.com,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] rust: add abstraction for struct device

On Wed, Jun 12, 2024 at 04:51:42PM +0200, Danilo Krummrich wrote:
> On 6/11/24 18:13, Boqun Feng wrote:
> > On Tue, Jun 11, 2024 at 03:29:22PM +0200, Greg KH wrote:
> > > On Tue, Jun 11, 2024 at 03:21:31PM +0200, Danilo Krummrich wrote:
> > > > ...hence, I agree we should indeed add to the #Invariants and #Safety section
> > > > that `->release` must be callable  from any thread.
> > > > 
> > > > However, this is just theory, do we actually have cases where `device::release`
> > 
> > @Danilo, right, it's only theorical, but it's good to call it out since
> > it's the requirement for a safe Rust abstraction.
> 
> Similar to my previous reply, if we want to call this out as safety requirement
> in `Device::from_raw`, we probably want to add it to the documentation of the C
> `struct device`, such that we can argue that this is an invariant of C's
> `struct device`.
> 
> Otherwise we'd have to write something like:
> 
> "It must also be ensured that the `->release` function of a `struct device` can
> be called from any non-atomic context. While not being officially documented this
> is guaranteed by the invariant of `struct device`."

In the 20+ years of the driver model being part of the kernel, I don't
think this has come up yet, so maybe you can call the release function
in irq context.  I don't know, I was just guessing :)

So let's not go adding constraints that we just do not have please.
Same goes for the C code, so the rust code is no different here.

thanks,

greg k-h