On Thu, Nov 12, 2020 at 11:28 PM Steven Rostedt <rost...@goodmis.org> wrote: > > On Thu, 12 Nov 2020 17:10:30 +0900 > Byungchul Park <byungchul.p...@lge.com> wrote: > > > 2. Does Lockdep do what a deadlock detection tool should do? From > > internal engine to APIs, all the internal data structure and > > algotithm of Lockdep is only looking at lock(?) acquisition order. > > Fundamentally Lockdep cannot work correctly with all general cases, > > for example, read/write/trylock and any wait/event. > > But lockdep does handle read/write/trylock and can handle wait/event (just > needs better wrappers to annotate this). Perhaps part of the confusion here > is that we believe that lockdep already does what you are asking for. > > > > > This can be done by re-introducing cross-release but still partially. > > A deadlock detector tool should thoroughly focus on *waits* and > > *events* to be more perfect at detecting deadlock because the fact is > > *waits* and their *events* that never reach cause deadlock. > > > > With the philosophy of Lockdep, we can only handle partial cases > > fundamently. We have no choice but to do various work-around or adopt > > tricky ways to cover more cases if we keep using Lockdep. > > > > > That said, I'm not at all interested in a wholesale replacement of > > > lockdep which will take exactly the same amount of time to stabilize and > > > weed out the shortcomings again. > > > > I don't want to bother ones who don't want to be bothered from the tool. > > But I think some day we need a new tool doing exactly what it should do > > for deadlock detection for sure. > > > > I'm willing to make it matured on my own, or with ones who need a > > stronger tool or willing to make it matured together - I wish tho. > > That's why I suggest to make both there until the new tool gets > > considered stable. > > > > FYI, roughly Lockdep is doing: > > > > 1. Dependency check > > 2. Lock usage correctness check (including RCU) > > 3. IRQ related usage correctness check with IRQFLAGS > > > > 2 and 3 should be there forever which is subtle and have gotten matured. > > But 1 is not. I've been talking about 1. But again, it's not about > > replacing it right away but having both for a while. I'm gonna try my > > best to make it better. > > And I believe lockdep does handle 1. Perhaps show some tangible use case > that you want to cover that you do not believe that lockdep can handle. If > lockdep cannot handle it, it will show us where lockdep is lacking. If it > can handle it, it will educate you on other ways that lockdep can be > helpful in your development ;-)
Yes. That's the best thing I can do for all of us. I will. I already did exactly the same thing while I was developing cross-release. But I'm willing to do it again with the current Lockdep code. But not today. It's over mid-night. Good night~ -- Thanks, Byungchul