Date:   Thu, 12 Nov 2020 23:58:44 +0900
From:   Byungchul Park <max.byungchul.park@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     Byungchul Park <byungchul.park@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
        will@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        alexander.levin@...rosoft.com,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Chris Wilson <chris@...is-wilson.co.uk>, duyuyang@...il.com,
        johannes.berg@...el.com, Tejun Heo <tj@...nel.org>,
        "Theodore Ts'o" <tytso@....edu>, willy@...radead.org,
        david@...morbit.com, Amir Goldstein <amir73il@...il.com>,
        bfields@...ldses.org, gregkh@...uxfoundation.org,
        kernel-team <kernel-team@....com>
Subject: Re: [RFC] Are you good with Lockdep?

On Thu, Nov 12, 2020 at 11:28 PM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 12 Nov 2020 17:10:30 +0900
> Byungchul Park <byungchul.park@....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

Powered by blists - more mailing lists