Torvalds wrote: > On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park <byungchul.park@xxxxxxx> wrote: >> >> I've been developing a tool for detecting deadlock possibilities by >> tracking wait/event rather than lock(?) acquisition order to try to >> cover all synchonization machanisms. It's done on v6.2-rc2. > > Ugh. I hate how this adds random patterns like I undertand what you mean.. But all the synchronization primitives should let DEPT know the beginning and the end of each. However, I will remove the 'if' statement that looks ugly from the next spin, and place the pattern to a better place if possible. > if (timeout == MAX_SCHEDULE_TIMEOUT) > sdt_might_sleep_strong(NULL); > else > sdt_might_sleep_strong_timeout(NULL); > ... > sdt_might_sleep_finish(); > > to various places, it seems so very odd and unmaintainable. > > I also recall this giving a fair amount of false positives, are they all fixed? Yes. Of course I removed all the false positives we found. > Anyway, I'd really like the lockdep people to comment and be involved. > We did have a fairly recent case of "lockdep doesn't track page lock > dependencies because it fundamentally cannot" issue, so DEPT might fix > those kinds of missing dependency analysis. See Sure. That's exactly what DEPT works for e.g. PG_locked. > https://lore.kernel.org/lkml/00000000000060d41f05f139aa44@xxxxxxxxxx/ I will reproduce it and share the result. > for some context to that one, but at teh same time I would *really* > want the lockdep people more involved and acking this work. > > Maybe I missed the email where you reported on things DEPT has found > (and on the lack of false positives)? Maybe you didn't miss. It's still too hard to make a decision between: Aggressive detection with false alarms that need to be fixed by manual classification as Lockdep did, focusing on potential possibility more. versus Conservative detection with few false alarms, which requires us to test much longer to get result we expect, focusing on actual happening. > > Linus Byungchul
