[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38620c47-62ea-40b6-a7b3-afee9a3238a3@leemhuis.info>
Date: Fri, 27 Sep 2024 10:59:01 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
<regressions@...mhuis.info>
To: 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>
Subject: Re: [regression] frozen usb mouse pointer at boot
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! ¯\_(ツ)_/¯
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!
"""
Ciao, Thorsten
Powered by blists - more mailing lists