Re: [PATCH 01/24] rust: driver core: drop drvdata before devres release

[Danilo Krummrich]

On Thu Apr 30, 2026 at 11:12 AM CEST, Alice Ryhl wrote:
> On Tue, Apr 28, 2026 at 12:10:59AM +0200, Danilo Krummrich wrote:
>> Move the post_unbind_rust callback before devres_release_all() in
>> device_unbind_cleanup().
>> 
>> With drvdata() removed, the driver's bus device private data is only
>> accessible by the owning driver itself. It is hence safe to drop the
>> driver's bus device private data before devres actions are released.
>> 
>> This reordering is the key enabler for Higher-Ranked Lifetime Types
>> (HRT) in Rust device drivers -- it allows driver structs to hold direct
>> references to devres-managed resources, because the bus device private
>> data (and with it all such references) is guaranteed to be dropped while
>> the underlying devres resources are still alive.
>> 
>> Without this change, devres resources would be freed first, leaving the
>> driver's bus device private data with dangling references during its
>> destructor.
>> 
>> Signed-off-by: Danilo Krummrich <dakr@xxxxxxxxxx>
>> ---
>>  drivers/base/dd.c             | 2 +-
>>  include/linux/device/driver.h | 4 ++--
>>  rust/kernel/driver.rs         | 4 ++--
>>  3 files changed, 5 insertions(+), 5 deletions(-)
>> 
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 5799a60fd058..be59d2e13a15 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -593,9 +593,9 @@ static DEVICE_ATTR_RW(state_synced);
>>  
>>  static void device_unbind_cleanup(struct device *dev)
>>  {
>> -	devres_release_all(dev);
>>  	if (dev->driver->p_cb.post_unbind_rust)
>>  		dev->driver->p_cb.post_unbind_rust(dev);
>> +	devres_release_all(dev);
>>  	arch_teardown_dma_ops(dev);
>>  	kfree(dev->dma_range_map);
>>  	dev->dma_range_map = NULL;
>
> I seem to recall that we discussed a plan to have two classes of devres
> callbacks where device unbind proceeds as follows:
>
> 1. Run first class of devres callbacks.
> 2. Device is now considered unbound.
> 3. Run second class of devres callbacks.
>
> Is that still the plan?

Yes, it is -- I have most patches for this around and landed some devres
prerequisites last cycle.

Also note that this series already makes the situation better in this regard,
since when drivers use HRT types rather than Devres, only Registration types
remain to be guarded by devres.