[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-20 20:21    [W:0.051 / U:1.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site