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
| ||
|
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