Hello Peter and Daniel, > Yeah, it are different lock instances, however by virtue of sharing the > same lock init site, they belong to the same lock class. Lockdep works > by tracking class dependancies, not instance dependancies.
The device and its parent both indeed have different pointers/instances. I saw that during debugging yesterday, so I already expected this was not really a bug, but a false positive of lockdep. > By generalizing to classes it can detect locking errors before they > actually occur. Basically that is a good thing... But... now we do not transfer the dev->sem to a mutex, because lockdep will start generating false positives, and thus we mask the lockdep error, by not converting the dev->sem to what it really is... This does give me a bad feeling about this... In short, we are implementing workarounds in good code code to hide bugs in debug-tooling... ?! So, any suggestions on how to fix lockdep? Anyone some good hints where I can start? Is it that fundamental to lockdep that it cannot be fixed without breaking it, or do we have to instrument the code that tells lockdep to ignore this particular mutex? Kind Regards, Remy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
