Re: [PATCH v2 3/3] driver core: take parent lock in async device attach

[Johan Hovold]

On Wed, Oct 14, 2026 at 10:52:48AM -0400, Alan Stern wrote:
> On Wed, Oct 14, 2026 at 03:31:09PM +0200, Johan Hovold wrote:
> > From: Mario Peter <mario.peter@xxxxxxxxxxxxxxxxxxxx>

> > Take the parent lock in __device_attach_async_helper() as well, like
> > __driver_attach_async_helper() does, and move
> > __device_driver_lock/unlock() up for that. With this the warning was
> > gone in 300 boots on the board and in 6000 iterations in QEMU.
> > 
> > Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
> > Assisted-by: LLM
> > Signed-off-by: Mario Peter <mario.peter@xxxxxxxxxxxxxxxxxxxx>

> > [ johan: switch to async_schedule_dev_nocall() to avoid deadlock if
> >          async_schedule_dev() runs synchronously when parent lock is
> > 	 held ]

> > @@ -1118,8 +1150,13 @@ static int __device_attach(struct device *dev, bool allow_async)
> >  	}
> >  out_unlock:
> >  	device_unlock(dev);
> > -	if (async)
> > -		async_schedule_dev(__device_attach_async_helper, dev);
> > +	if (async) {
> > +		if (!async_schedule_dev_nocall(__device_attach_async_helper, dev)) {
> > +			put_device(dev);
> > +			ret = 2;	/* retry synchronously */
> > +		}
> > +	}
> > +
> >  	return ret;
> >  }
> >  
> > @@ -1146,48 +1183,20 @@ EXPORT_SYMBOL_GPL(device_attach);
> >  void device_initial_probe(struct device *dev)
> >  {
> >  	struct subsys_private *sp = bus_to_subsys(dev->bus);
> > +	int ret;
> >  
> >  	if (!sp)
> >  		return;
> >  
> > -	if (sp->drivers_autoprobe)
> > -		__device_attach(dev, true);
> > +	if (sp->drivers_autoprobe) {
> > +		ret = __device_attach(dev, true);
> > +		if (ret == 2)
> > +			__device_attach(dev, false);
> > +	}
> >  
> >  	subsys_put(sp);
> >  }
> 
> These two pieces do not seem to be related to the changes mentioned in 
> the patch description.  Are they leftovers from some other patch?

They are needed since async_schedule_dev() may execute the callback
synchronously and in which case we'll deadlock if the caller already
holds the parent mutex (e.g. during initial probe).

I only highlighted the issue in the trailer section of the patch,
perhaps I should have amended the commit message proper.

Johan