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

["Danilo Krummrich" <dakr@kernel.org>]

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. :)

>> -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.

[1] https://elixir.bootlin.com/linux/v6.19-rc4/source/drivers/base/dd.c#L555