linux-kernel - Re: Possible hungtask issue will be introduced with device_lock() in uevent

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <6791a45f711e2_9b922948@dwillia2-mobl3.amr.corp.intel.com.notmuch>
Date: Wed, 22 Jan 2025 18:07:27 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "zhangzekun (A)" <zhangzekun11@...wei.com>, Greg KH
	<gregkh@...uxfoundation.org>
CC: <dan.j.williams@...el.com>, <linux-kernel@...r.kernel.org>,
	<rafael.j.wysocki@...el.com>, <regressions@...ts.linux.dev>, <tj@...nel.org>,
	<alex.williamson@...hat.com>, <chenjun102@...wei.com>
Subject: Re: Possible hungtask issue will be introduced with device_lock() in
 uevent_show()

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.