lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+agTiEF-1i9LbAgp-q_02oYF0kAPZGAAJ==-wx2Xh7xzQ@mail.gmail.com>
Date:   Wed, 16 Sep 2020 14:14:02 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: [PATCH v2] lockdep: Allow tuning tracing capacity constants.

On Wed, Sep 16, 2020 at 1:51 PM <peterz@...radead.org> wrote:
>
> On Wed, Sep 16, 2020 at 01:28:19PM +0200, Dmitry Vyukov wrote:
> > On Fri, Sep 4, 2020 at 6:05 PM Tetsuo Handa
> > <penguin-kernel@...ove.sakura.ne.jp> wrote:
> > >
> > > Hello. Can we apply this patch?
> > >
> > > This patch addresses top crashers for syzbot, and applying this patch
> > > will help utilizing syzbot's resource for finding other bugs.
> >
> > Acked-by: Dmitry Vyukov <dvyukov@...gle.com>
> >
> > Peter, do you still have concerns with this?
>
> Yeah, I still hate it with a passion; it discourages thinking. A bad
> annotation that blows up the lockdep storage, no worries, we'll just
> increase this :/
>
> IIRC the issue with syzbot is that the current sysfs annotation is
> pretty terrible and generates a gazillion classes, and syzbot likes
> poking at /sys a lot and thus floods the system.
>
> I don't know enough about sysfs to suggest an alternative, and haven't
> exactly had spare time to look into it either :/
>
> Examples of bad annotations is getting every CPU a separate class, that
> leads to nr_cpus! chains if CPUs arbitrarily nest (nr_cpus^2 if there's
> only a single nesting level).

Maybe on "BUG: MAX_LOCKDEP_CHAINS too low!" we should then aggregate,
sort and show existing chains so that it's possible to identify if
there are any worst offenders and who they are.

Currently we only have a hypothesis that there are some worst
offenders vs lots of normal load. And we can't point fingers which
means that, say, sysfs, or other maintainers won't be too inclined to
fix anything.

If we would know for sure that lock class X is guilty. That would make
the situation much more actionable.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ