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

[Johan Hovold <johan@kernel.org>]

On Wed, Oct 14, 2026 at 04:42:09PM +0200, Danilo Krummrich wrote:
> On Wed Oct 14, 2026 at 10:15 AM CEST, Johan Hovold wrote:

> > But it's driver core that needs the extra reference. It seems
> > reasonable to require that any subsystem that sets a new
> > type->need_parent_lock also makes sure that any device of that type
> > holds a reference to its parent. And importantly, it's already the case
> > for the only user of this feature today (i.e. USB interfaces).
> 
> Exactly, it is the driver core that needs the extra reference count; for a field
> that is owned by the driver core, and for which the driver core manages its
> lifetime.  If it needs an additional reference count for async or deferred work
> it should obtain the reference count for this scope explicitly.

As I've mentioned, it's not just for async or deferred probe. It's also
needed when a driver gets added or when probe is triggered through
sysfs. The bus iterators only takes a reference to the each device and
not their parents before calling __driver_attach() etc.

> USB interfaces already holding an additional reference makes the proposed
> contract work for today's user, but I'd rather not make that prerequisite of the
> API.  It would push a prerequisite for an implementation detail to the user.

I understand your concern, but my reasoning is that this feature is only
needed when devices are tightly coupled with their parents and where it
therefore probably always make sense to pin the parent.

Note that the need_parent_lock flag is now set in the device type struct
which also holds a pointer to the release function that drops the
reference. So it's pretty easy to check any theoretical further users.

> Please, let's not add this API contract. Let's have the driver core deal with
> this internally.

I can take another look at it, but the alternatives seemed either error
prone or a bit icky (e.g. a helper that returns a reference to the
parent after checking the dead flag under the device lock).

Johan