Re: [PATCH v1] driver core: Don't take the device lock in waiting_for_supplier_show()

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Sat, Oct 17, 2026 at 08:18:37PM -0400, Nickolai Zeldovich wrote:
> Reading a device's waiting_for_supplier attribute while the device is
> being probed hangs both the reader and the probing task for good, in
> uninterruptible sleep, if the probe succeeds. The file is world
> readable and fw_devlink, enabled by default, creates it for every
> device with a firmware node until the device is bound, so any user
> reading sysfs during a probe (udev, a tool walking /sys, a plain cat)
> can wedge it. The probing task keeps holding the device lock, so the
> module load or deferred probe work that ran the probe, and everything
> that takes that device's lock later, hangs as well. Kernels since v5.9
> are affected.
> 
> waiting_for_supplier_show() blocks in device_lock() while the read
> holds an active reference on the sysfs file. On successful probe,
> driver_bound() calls device_links_driver_bound() with the device lock
> held, which removes the file, and kernfs waits for that active
> reference to be dropped: the reader waits for the prober and the
> prober for the reader. Lockdep does not report it because dev->mutex
> is not validated.
> 
> The device lock is not needed here. The value is computed by
> fwnode_links_check_suppliers() under fwnode_link_lock, which every
> writer of the fwnode supplier list holds, and the active reference keeps
> the device from being deleted while the callback runs. Drop the device
> lock.
> 
> Reproduced on x86_64 under QEMU with an lsi53c895a SCSI controller and
> sym53c8xx built as a module: its probe resets the SCSI bus and the
> synchronous scan then waits for the settle delay (3 seconds by default),
> and a read of the PCI device's waiting_for_supplier file 1 second into
> the module load hangs. Before the change the hung task detector reports
> insmod in kernfs_drain() under device_links_driver_bound() and cat in
> waiting_for_supplier_show(), neither ever returns, and a power-off
> afterwards hangs in device_shutdown() on the same lock; after the
> change the read returns 0 and the module load completes.
> 
> Fixes: da6d647598a6 ("driver core: Add waiting_for_supplier sysfs file for devices")
> Assisted-by: LLM
> Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
> ---
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot