Re: Possible hungtask issue will be introduced with device_lock() in uevent_show()

[Dan Williams <dan.j.williams@intel.com>]

zhangzekun (A) wrote:
> 
> 
> 在 2024/12/31 16:26, Greg KH 写道:
> > On Tue, Dec 31, 2024 at 03:56:08PM +0800, Zhang Zekun wrote:
> >> Hi, Dan, Greg,
> >>
> >> We have found a potential tungtask issue has been introduce by commit 9a71892cbcdb ("Revert "driver core: Fix uevent_show() vs driver detach race""), which revert the rcu in device_uevent but reintroduce the device_lock() in uevent_show(). The reproduce procedure is quite simple:
> > 
> > The revert just puts the original logic back in place, so this is not
> > anything new that has been introduced, right?  It's just that the
> > attempted fix didn't work, so a different fix needs to happen.
> Hi, Greg,
> 
> Yes, there is nothing new introduced here. We have been testing the rcu 
> fix (commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver 
> detach race")) for monthes but has not obersved problems.

Hi Zekun,

If you have some cycles to help investigate the replacement fix that
would be much appreciated.

So far I came up with this:

http://lore.kernel.org/172790598832.1168608.4519484276671503678.stgit@dwillia2-xfh.jf.intel.com

...but have not had time to debug the 0day report.

My worry is still that Linux has long since shipped the expectation that
reading 'uevent' bounces the device_lock() which, among other things,
makes sure that any in-flight driver probing has completed.

The report of USB devices disappearing is consistent with a udev
operation failing due to the driver not being done attaching, or
something similar.

So even though you have not seen any issues, I suspect small differences
in the devices on your system and the reporter's system, or udev rule
differences could result in a failure to trigger the regression.