Re: [regression] frozen usb mouse pointer at boot

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

[ add tools@kernel.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@disroot.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".