All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: rafael.j.wysocki@intel.com, tj@kernel.org,
	linux-kernel@vger.kernel.org, regressions@lists.linux.dev
Subject: Re: [PATCH] driver core: Fix userspace expectations of uevent_show() as a probe barrier
Date: Tue, 1 Oct 2024 08:50:15 +0200	[thread overview]
Message-ID: <2024100130-turkey-duplicate-d670@gregkh> (raw)
In-Reply-To: <172772671177.1003633.7355063154793624707.stgit@dwillia2-xfh.jf.intel.com>

On Mon, Sep 30, 2024 at 01:05:13PM -0700, Dan Williams wrote:
> Commit "driver core: Fix uevent_show() vs driver detach race" [1]
> attempted to fix a lockdep report in uevent_show() by making the lookup
> of driver information for a given device lockless. It turns out that
> userspace likely depends on the side-effect of uevent_show() flushing
> device probing, as evidenced by the removal of the lock causing a
> regression initializing USB devices [2].
> 
> Introduce a new "locked" type for sysfs attributes that arranges for the
> attribute to be called under the device-lock, but without setting up a
> reverse locking order dependency with the kernfs_get_active() lock.

As this is "only" for the driver core, can you move some of the stuff in
the global .h files to the local ones so that no one else gets the wrong
idea they can use them?

thanks,

greg k-h

  reply	other threads:[~2024-10-01  6:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30 20:05 [PATCH] driver core: Fix userspace expectations of uevent_show() as a probe barrier Dan Williams
2024-10-01  6:50 ` Greg KH [this message]
2024-10-02 21:51   ` Dan Williams

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=2024100130-turkey-duplicate-d670@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=dan.j.williams@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.