linux-kernel - Re: [RFC PATCH 0/3] sysfs: allow suicide

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 25 Mar 2009 17:42:55 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alex Chiang <achiang@...com>
Cc:	htejun@...il.com, greg@...ah.com, cornelia.huck@...ibm.com,
	stern@...land.harvard.edu, kay.sievers@...y.org,
	rusty@...tcorp.com.au, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] sysfs: allow suicide

Alex Chiang <achiang@...com> writes:

> * Eric W. Biederman <ebiederm@...ssion.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/