On 2020/11/19 0:10, Peter Zijlstra wrote: > On Wed, Nov 18, 2020 at 11:30:05PM +0900, Tetsuo Handa wrote: >> The problem is that we can't know what exactly is consuming these resources. >> My question is do you have a plan to make it possible to know what exactly is >> consuming these resources. > > I'm pretty sure it's in /proc/lockdep* somewhere.
OK. Then... Dmitry, can you update syzkaller to dump /proc/lockdep* before terminating as a crash as soon as encountering one of BUG: MAX_LOCKDEP_ENTRIES too low! BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! BUG: MAX_LOCKDEP_CHAINS too low! BUG: MAX_LOCKDEP_KEYS too low! WARNING in print_bfs_bug messages? On 2020/09/16 21:14, Dmitry Vyukov wrote: > On Wed, Sep 16, 2020 at 1:51 PM <pet...@infradead.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-ker...@i-love.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 <dvyu...@google.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. >
