Re: [PATCH v2] driver core: Take parent lock in async device attach

[Danilo Krummrich]

On Mon Oct 12, 2026 at 2:50 PM CEST, Johan Hovold wrote:
> On Wed, Oct 07, 2026 at 01:15:14PM +0000, Mario Peter wrote:
>> On buses with need_parent_lock set (only USB), probe() must run with the
>> parent device locked. A synchronous attach after device_add() gets this
>> from the caller, e.g. usb_set_configuration() holds the udev lock while
>> adding interfaces. __device_attach_async_helper() runs the probe from an
>> async worker instead, where that lock isn't held, and only takes
>> device_lock(dev).
>
>> 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>
>> ---
>> v2:
>> - Describe the race in more detail
>> - Keep the multi-TT detail, but say why the hub has to be multi-TT
>>   for this symptom
>> - Reproduce and test on v7.3-rc6 in QEMU
>> 
>> In the same QEMU setup, a debug-only device_lock_assert(&udev->dev) in
>> usb_probe_interface() fired on every async probe of a hub interface
>> without this patch (52 of 52) and never with it (0 of 102). The hub
>> emulator and the test scripts are small, I can post them if that helps.
>
> Thanks for fixing this, USB interfaces should indeed always be probed
> with the parent lock held:

I was about to pick this up, but can't this cause a subtle deadlock? What if
async_schedule_dev() runs synchronously? Wouldn't we then attempt to take the
parent lock again while e.g. bConfigurationValue_store() already holds it?