mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "zhangzekun (A)" <zhangzekun11@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: <dan.j.williams@intel.com>, <linux-kernel@vger.kernel.org>,
	<rafael.j.wysocki@intel.com>, <regressions@lists.linux.dev>,
	<tj@kernel.org>, <alex.williamson@redhat.com>,
	<chenjun102@huawei.com>
Subject: Re: Possible hungtask issue will be introduced with device_lock() in uevent_show()
Date: Sat, 4 Jan 2025 14:02:54 +0800	[thread overview]
Message-ID: <7b599394-d1a1-4e13-9c5c-48321172ec65@huawei.com> (raw)
In-Reply-To: <2024123128-monetize-outtakes-3260@gregkh>



在 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.

Noticing that, brmails+k write in bugzilla "Also, I can't say why the 
issue appeared in the past even without this commit being present, as I 
haven't bisected any kernel version before v6.6.45.". I doubt that there 
could still have problem described in bugzilla [1] even if commit 
c0a40097f0bc ("drivers: core: synchronize really_probe() and 
dev_uevent()") has been reverted, and the problem is not directly 
introduced by rcu in dev_uevent.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=219244

Thanks,
Zekun

  reply	other threads:[~2025-01-04  6:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02 21:54 [PATCH v2] driver core: Fix userspace expectations of uevent_show() as a probe barrier Dan Williams
2024-10-07  9:39 ` kernel test robot
2024-10-08  0:26 ` Dan Williams
2024-10-13 15:00   ` Greg KH
2024-10-28  9:08   ` Thorsten Leemhuis
2024-10-28 22:57     ` Dan Williams
2024-10-29  0:21       ` Greg KH
2024-12-31  7:56 ` Possible hungtask issue will be introduced with device_lock() in uevent_show() Zhang Zekun
2024-12-31  8:26   ` Greg KH
2025-01-04  6:02     ` zhangzekun (A) [this message]
2025-01-04  8:14       ` Greg KH
2025-01-23  2:07       ` Dan Williams
2025-01-27  3:27         ` zhangzekun (A)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b599394-d1a1-4e13-9c5c-48321172ec65@huawei.com \
    --to=zhangzekun11@huawei.com \
    --cc=alex.williamson@redhat.com \
    --cc=chenjun102@huawei.com \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=regressions@lists.linux.dev \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®