Message-ID: <66f71b1452d7a_964f22940@dwillia2-xfh.jf.intel.com.notmuch>
Date: Fri, 27 Sep 2024 13:52:36 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Linux regression tracking (Thorsten Leemhuis)"
	<regressions@...mhuis.info>, Dan Williams <dan.j.williams@...el.com>, "Greg
 Kroah-Hartman" <gregkh@...uxfoundation.org>, Linux regressions mailing list
	<regressions@...ts.linux.dev>
CC: LKML <linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>, <tools@...nel.org>
Subject: Re: [regression] frozen usb mouse pointer at boot

[ add tools@...nel.org for bugzilla bridge mention ]

Linux regression tracking (Thorsten Leemhuis) wrote:
> On 24.09.24 04:54, Dan Williams wrote:
> > Dan Williams wrote:
> >> Greg Kroah-Hartman wrote:
> >> [..]
> >>>
> >>> This is odd.
> >>>
> >>> Does the latest 6.10.y release also show this problem?
> >>>
> >>> I can't duplicate this here, and it's the first I've heard of it (given
> >>> that USB mice are pretty popular, I would suspect others would have hit
> >>> it as well...)
> >>
> >> Sorry for missing this earlier. One thought is that userspace has a
> >> dependency on uevent_show() flushing device probing. In other words the
> >> side effect of taking the device_lock() in uevent_show() is that udev
> >> might enjoy some occasions where the reading the uevent flushes probing
> >> before the udev rule runs. With this change, uevent_show() no longer
> >> waits for any inflight probes to complete.
> >>
> >> One idea to fix this problem is to create a special case sysfs attribute
> >> type that takes the device_lock() before kernfs_get_active() to avoid
> >> the deadlock on attribute teardown.
> >>
> >> I'll take a look. Thanks for forwarding the report Thorsten!
> > 
> > Ok, the following boots and passes the CXL unit tests, would appreciate
> > if the reporter can give this a try:
> 
> Somehow I apparently became a "bugzilla-man-in-the-middle interface" yet
> again... But whatever! ¯\_(ツ)_/¯

Oh, sorry about that Thorsten, for some reason I thought we were living
in this new world that Konstantin mentions where mailing-list to
bugzilla communication is automated. Hopefully that arrives soon.

I very much appreciate the help here and thank you for the hard work
you put into taking care of regressions!

> 
> To forward the latest comment from the ticket:
> 
> """
> --- Comment #11 from brmails+k@...root.org ---
> Good news!
> 
> I think the proposed patch by Dan Williams fixes the issue.
> 
> I have tested it with v6.6.52 and v6.10.11. I haven't been able to
> recreate the
> issue with those modified kernels even once.
> 
> The patch can be applied to v6.11.0 and v6.10.11 out of the box. For
> v6.6.52 I
> had to slightly modify it as the line
> 
> #define SYSFS_GROUP_INVISIBLE   020000
> 
> doesn't exist in /include/linux/sysfs.h in v6.6.52 hence the patch
> looking for
> that line fails on that file.
> But after adjusting the patch accordingly, the patch works fine on
> v6.6.52 and
> the issue is gone with the patched version of v6.6.52, just like 6.10.11.
> 
> So, I assume that the fix / patch proposed by Dan Williams works as intended
> resolving the issue I had.
> 
> Thanks again for forwarding the bug report and for the quick fix!
> """

Great news, I'll revise the patch a bit to add some clarifying
documentation. Specifically, that the new DEVICE_ATTR_RW_LOCKED() is
only for exceptional corner cases like uevent_show(), and that most
usages of "dev->driver" in a sysfs attribute are best served by being
declared as part of "drv_groups".

Powered by blists - more mailing lists