linux-kernel - Re: deadlock in "modprobe -r ohci1394" shortly after "modprobe ohci1394"

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: <Pine.LNX.4.44L0.0611201415000.7569-100000@iolanthe.rowland.org>
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/