Re: driver/base/dd.c lockdep warning

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 01, Alan Stern wrote:

> On Tue, 1 Sep 2009, Jan Blunck wrote:
> 
> > > This is semaphore->mutex conversion madness from tglx.  What he tried 
> > > to do just doesn't work with lockdep.
> > > 
> > 
> > If this is a parent->child relationship and the parent is always locked before
> > the child this works perfectly with lockdep. The inode->i_mutex is doing
> > it. How is the lock in your code different from that?
> 
> Maybe you're right and it's not different.  I'm not so sure.  What
> about parent-child-grandchild relationships?  What about situations
> where multiple siblings are locked concurrently after first acquiring
> the parent's lock to make it safe (not that I'm aware of any such
> things occurring in the kernel, but they might)?

You have to come up with a locking order on the siblings to make it deadlock
free. After that you teach the locking order to lockdep and everything should
be fine.

If nobody is working on this I'll try to come up with a few patches tomorrow.

Cheers,
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux