linux-kernel - Re: [PATCH 6/6] rust: driver: drop device private data post unbind

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: <2026010701-rearview-retriever-3268@gregkh>
Date: Wed, 7 Jan 2026 15:54:33 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Danilo Krummrich <dakr@...nel.org>
Cc: rafael@...nel.org, igor.korotin.linux@...il.com, ojeda@...nel.org,
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
	lossin@...nel.org, a.hindborg@...nel.org, aliceryhl@...gle.com,
	tmgross@...ch.edu, david.m.ertman@...el.com, ira.weiny@...el.com,
	leon@...nel.org, bhelgaas@...gle.com, kwilczynski@...nel.org,
	wsa+renesas@...g-engineering.com, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-i2c@...r.kernel.org
Subject: Re: [PATCH 6/6] rust: driver: drop device private data post unbind

On Wed, Jan 07, 2026 at 01:50:43PM +0100, Danilo Krummrich wrote:
> On Wed Jan 7, 2026 at 1:22 PM CET, Greg KH wrote:
> > On Wed, Jan 07, 2026 at 11:35:05AM +0100, Danilo Krummrich wrote:
> >> @@ -548,6 +548,10 @@ static DEVICE_ATTR_RW(state_synced);
> >>  static void device_unbind_cleanup(struct device *dev)
> >>  {
> >>  	devres_release_all(dev);
> >> +#ifdef CONFIG_RUST
> >
> > Nit, let's not put #ifdef in .c files, the overhead of an empty pointer
> > for all drivers is not a big deal.
> 
> I agree, I mainly did it to make it clear that, as by now, this is only used by
> Rust driver-core code. However, ...
> 
> >> +	if (dev->driver->p_cb.post_unbind)
> >> +		dev->driver->p_cb.post_unbind(dev);
> >> +#endif
> 
> <snip>
> 
> >> +	struct {
> >> +		/*
> >> +		 * Called after remove() and after all devres entries have been
> >> +		 * processed.
> >> +		 */
> >> +		void (*post_unbind)(struct device *dev);
> >
> > post_unbind_rust_only()?
> 
> ...this works as well. We can always rename it, in case we start using it in C
> too.
> 
> So, I'm fine with either. :)

I say name it with "rust_" and take out the #ifdef, that makes it
simpler/easier to understand.

> >> -impl<T: RegistrationOps> Registration<T> {
> >> +impl<T: RegistrationOps + 'static> Registration<T> {
> >> +    extern "C" fn post_unbind_callback(dev: *mut bindings::device) {
> >> +        // SAFETY: The driver core only ever calls the post unbind callback with a valid pointer to
> >> +        // a `struct device`.
> >> +        //
> >> +        // INVARIANT: `dev` is valid for the duration of the `post_unbind_callback()`.
> >> +        let dev = unsafe { &*dev.cast::<device::Device<device::CoreInternal>>() };
> >> +
> >> +        // `remove()` and all devres callbacks have been completed at this point, hence drop the
> >> +        // driver's device private data.
> >> +        //
> >> +        // SAFETY: By the safety requirements of the `Driver` trait, `T::DriverData` is the
> >> +        // driver's device private data.
> >> +        drop(unsafe { dev.drvdata_obtain::<T::DriverData>() });
> >
> > I don't mind this, but why don't we also do this for all C drivers?
> 
> What exactly do you mean? Manage the lifetime of the device private data
> commonly in driver-core code?
> 
> > Just null out the pointer at this point in time so that no one can touch
> > it, just like you are doing here (in a way.)
> 
> I think device_unbind_cleanup() already calls dev_set_drvdata(dev, NULL) [1], so
> technically we do not have to do it necessarily in Device::drvdata_obtain() as
> well.
> 
> However, with Device::drvdata_obtain() we take back ownership of the
> Pin<KBox<T>> stored in dev->driver_data, so it makes sense to null out the
> pointer at exactly this point in time.

Ok, no objection from me.

thanks,

greg k-h