All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang@hp.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: htejun@gmail.com, greg@kroah.com, cornelia.huck@de.ibm.com,
	stern@rowland.harvard.edu, kay.sievers@vrfy.org,
	rusty@rustcorp.com.au, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] sysfs: allow suicide
Date: Wed, 25 Mar 2009 16:54:14 -0600	[thread overview]
Message-ID: <20090325225414.GA11447@ldl.fc.hp.com> (raw)
In-Reply-To: <m13ad2xi46.fsf@fess.ebiederm.org>

* Eric W. Biederman <ebiederm@xmission.com>:
> 
> Interesting.
> 
> Fixing a read/writer deadlock by allowing the writers to nest
> inside the readers.
> 
> My first impression is that it is too clever.

Clever points go to Tejun. All I did was refresh the series
slightly. :)

> Furthermore I think this is walking around the edges of a more
> general problem.   How should we serial hotplug and hotunplug
> in general.  In what context should remove methods run in.
> 
> My impression is that we have a huge hole in our infrastructure
> for hotplug drivers.  Problems like how do we get a user space
> context for the code to run in and how do we handle
> multiple hotplug actions for overlapping device trees from
> stomping on each other.
> 
> My hypothesis is once we solve this for the general case of
> device hotplug and removal we won't need special support from
> sysfs.  At least not in the suicidal way.

I agree that we have problems in our infrastructure, especially,
as you point out, overlapping device trees, etc.

I see your point about adding extra cruft into sysfs to work
around a special case while leaving the hard problem unsolved.

Perhaps the status quo is better. I do think that getting
suicidal sysfs attributes off the global workqueue is a band-aid
that actually helps, vs. the proposed patches here which are
questionable in nature.

Oh well.

Thanks for the comments.

/ac

> 
> We still have very weird cases such as the lock inversion that
> we have today between rtnl_lock and active reference count,
> coming from the networking code.
> 
> Eric
> 

  reply	other threads:[~2009-03-25 22:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-25  4:16 [RFC PATCH 0/3] sysfs: allow suicide Alex Chiang
2009-03-25  4:16 ` [RFC PATCH 1/3] sysfs: make the sysfs_addrm_cxt->removed list FIFO Alex Chiang
2009-03-25  4:16 ` [RFC PATCH 2/3] sysfs: add blocking notifier to prohibit module unload Alex Chiang
2009-03-25  4:17 ` [RFC PATCH 3/3] sysfs: care-free suicide for sysfs files Alex Chiang
2009-03-26  5:24   ` Tejun Heo
2009-03-25  5:54 ` [RFC PATCH 0/3] sysfs: allow suicide Eric W. Biederman
2009-03-25 22:54   ` Alex Chiang [this message]
2009-03-26  0:42     ` Eric W. Biederman
2009-03-26  1:26       ` Alex Chiang
2009-03-26  2:41         ` Eric W. Biederman
2009-03-26  1:32       ` Tejun Heo
2009-03-26  3:05         ` Eric W. Biederman
2009-03-26  3:36           ` Tejun Heo
2009-03-26 14:21             ` Alan Stern
2009-03-26 14:56               ` Cornelia Huck
2009-03-25 14:45 ` Alan Stern
2009-03-25 23:03   ` Alex Chiang

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=20090325225414.GA11447@ldl.fc.hp.com \
    --to=achiang@hp.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=htejun@gmail.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=stern@rowland.harvard.edu \
    /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.