On Dec 30, 2007 6:01 AM, Alan Stern <[EMAIL PROTECTED]> wrote: > > On Sat, 29 Dec 2007, Dave Young wrote: > > > On Dec 29, 2007 1:06 PM, Dave Young <[EMAIL PROTECTED]> wrote: > > > > > > On Dec 29, 2007 12:42 PM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Sat, Dec 29, 2007 at 10:36:49AM +0800, Dave Young wrote: > > > > > > > > > > > The full boot dmesg with lockdep output is out, there's one warnings > > > > > in it : > > > > > > > > Please fix that warning before the next repost of these patches (along > > > > with fixing the problem of them not being able to be applied and > > > > successfully built at every point in the series...) > > > > > > > > > > Ok, thanks, I will fix them and repost. > > > > > > > Hi, > > After digging the code, I feel hard to fix the lockdep warning due to > > some misterious relationship with usb. > > > > Could someone help on this? thanks. > > Add usb-devel list as cc > > The problem isn't specific to USB. And you will not be able to fix it > unless you make drastic changes to the lockdep checker. > > lockdep warns whenever a task acquires a mutex while holding another > mutex of the same kind (that is, the same member in another structure > of the same type). But there are lots of places where the kernel needs > to acquire dev->sem for one device while already holding > dev->parent->sem. There's no way to remove these, which means there's > no way to prevent lockdep from issuing a warning. > > Around a month ago I had a discussion with Peter Zijlstra about the > problems in converting the device semaphores to mutexes; you may be > able to find it in the LKML archives. Doing the conversion while > keeping lockdep happy is a very hard problem and we were not able to > solve it. >
It's unfortunate to know this, I will search and read your thread. > It's possible that you may be able to convert the semaphores in struct > class or other structures. But you won't succeed with struct device. > > Alan Stern > > - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html