From: ebiederm@xmission.com (Eric W. Biederman)
To: Alex Chiang <achiang@hp.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 17:42:55 -0700 [thread overview]
Message-ID: <m17i2dunao.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090325225414.GA11447@ldl.fc.hp.com> (Alex Chiang's message of "Wed\, 25 Mar 2009 16\:54\:14 -0600")
Alex Chiang <achiang@hp.com> writes:
> * 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.
Sounds like it. I'm not trying to shoot this down, rather
I'm trying to figure out how to solve this cleanly, as I am slowly
trying to sort out the pci hotplug and unplug issues.
I'm not certain how general we can be. pci layer, device layer or kobject
layer, but I think it makes sense to have a dedicated work queue to use
when devices are removed. As every hotplug driver currently has to
invent one. The fake hotplug code is very normal in this respect.
If we can get the work queue creation and the calling of remove put
into the generic pci layer, we should be able to simply all of the
hotplug controller drivers.
I'm not seeing a patch from you where you are using a separate
workqueue. Am I missing something? But if we can place that workqueue
in say the pci layer I think it would be just a little re factoring
and not a lot more code.
Eric
next prev parent reply other threads:[~2009-03-26 0:43 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
2009-03-26 0:42 ` Eric W. Biederman [this message]
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=m17i2dunao.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=achiang@hp.com \
--cc=cornelia.huck@de.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox