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]
Message-ID: <m17i2dunao.fsf@fess.ebiederm.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ