| 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: Mon, 20 Nov 2006 14:18:33 -0500 (EST) From: Alan Stern <stern@...land.harvard.edu> To: Dmitry Torokhov <dtor@...ightbb.com> cc: Stefan Richter <stefanr@...6.in-berlin.de>, <linux1394-devel@...ts.sourceforge.net>, Greg Kroah-Hartman <gregkh@...e.de>, <linux-kernel@...r.kernel.org> Subject: Re: deadlock in "modprobe -r ohci1394" shortly after "modprobe ohci1394" On Sun, 19 Nov 2006, Dmitry Torokhov wrote: > I was actually looking at the driver core recently and was surprised that > USB crapped all over it with its locking requirements. I don't think its a > good idea to enforce one subsystem's lcoking rules onto everyone. I agree. The only reason for doing it that way was I couldn't think of any other approach. > Would there be alot of objections if we add bus->[un]lock_device() and > hide all uglies there? If methods are not set when bus is registered then > standard dev->sem lock/unlock will be used. That's a little too simple to work. You can see from examining the existing code in bus.c and dd.c; there are places where the device needs to be locked but not the parent, places where the parent needs to be locked but not the device, and places where both need to be locked. A slightly different way to accomplish much the same thing might be to have a per-bus parent_needs_to_be_locked flag (or method). It wouldn't be quite as elegant, though. Alan Stern - 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