Re: [PATCH] driver core: take parent lock on deferred probe

[Danilo Krummrich]

On Wed Oct 14, 2026 at 4:38 AM CEST, Alan Stern wrote:
> I was going to suggest that the driver core could acquire and release 
> these extra references automatically for devices on a bus with 
> need_parent_lock set, but it looks like that can't be done because the 
> bus_type might not yet be set when device_initialize() runs.
>
> However, is there any real reason why the driver core wouldn't want to 
> guarantee that dev->parent will be a valid pointer up until the time 
> when dev is released?  For every device that has a parent, not just USB?

I'm not sure we don't have any cases where this would create cyclic reference
counts.  Like with the kobject API, the separate device_del() step would break
circular reference counts.

>From a quick check ALSA seems to have this cyclic topology.

> On the other hand, there's something a bit weird about this whole thing.  
> The problem arises when you want to probe a device whose parent has been 
> deleted.  Isn't there some sort of protection to prevent that from ever 
> happening?  I mean, doesn't deleting a device imply that all its 
> descendants have been (or are in the process of being) deleted?  And of 
> course, deleting and probing are mutually exclusive -- they can't race, 
> right?

Yes, that's what the dev->p->dead check under the device lock protects against.
But the new code accesses dev->parent before acquiring the device lock and
reaching that check.