All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sysfs: move assignment to be under lock in sysfs_remove_dir()
Date: Wed, 30 Oct 2013 15:38:32 -0700	[thread overview]
Message-ID: <20131030223832.GA29216@kroah.com> (raw)
In-Reply-To: <8738ni308z.fsf@xmission.com>

On Wed, Oct 30, 2013 at 02:41:16PM -0700, Eric W. Biederman wrote:
> One of the particularly problematic things that can happen with sysfs is
> that we can get a hotplug event in userspace and then examine sysfs and
> not find the attributes of the device because the kernel has not added
> them yet.
> 
> Which is a particularly good reason to have a campaign against
> independent usage of device_create_file and device_remove_file in the
> device users.

I have been working on that over the past few months, there are now
default attribute groups for all things, and those are used to create
the files _before_ the hotplug event goes to userspace.  I still have
more work to do to clean this up, but my goal is to remove
device_create_file() entirely, although we still have some work to go
for the platform driver case, which will take some time.

But we will get there eventually, it's a problem that has to be fixed as
more and more people hit this with multi-core, fast systems these days.

> At which point really the right thing to do when we delete a directory
> is to WARN and be very grumpy if there are any attributes in the
> directory we were removing.

We tried this once, and it was a mess.  But that was a long time ago,
maybe it's better now, I'll look and see...

thanks,

greg k-h

  parent reply	other threads:[~2013-10-30 22:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-29 22:09 [PATCH] sysfs: move assignment to be under lock in sysfs_remove_dir() Greg KH
2013-10-30  0:39 ` Eric W. Biederman
2013-10-30  1:25   ` Linus Torvalds
2013-10-30  5:29     ` Eric W. Biederman
2013-10-30 13:28       ` Tejun Heo
2013-10-30 14:28         ` [PATCH driver-core-next] sysfs: rename sysfs_assoc_lock and explain what it's about Tejun Heo
2013-10-30 22:29           ` Eric W. Biederman
2013-10-31 17:11             ` Tejun Heo
2013-10-30 21:41         ` [PATCH] sysfs: move assignment to be under lock in sysfs_remove_dir() Eric W. Biederman
2013-10-30 22:00           ` Tejun Heo
2013-10-30 22:38           ` Greg KH [this message]
2013-10-30 13:14 ` Tejun Heo
2013-10-30 21:42 ` Eric W. Biederman

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=20131030223832.GA29216@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.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.