linux-kernel - Re: [syzbot] [btrfs?] BUG: MAX_LOCKDEP_CHAIN

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+aSV8ZptNaLqVg+QgOyDn+tJ1WUyBxQ-9hk7joqbmT6GA@mail.gmail.com>
Date: Thu, 22 Aug 2024 14:05:01 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Josef Bacik <josef@...icpanda.com>, syzkaller <syzkaller@...glegroups.com>
Cc: syzbot <syzbot+dfb6eff2a68b42d557d3@...kaller.appspotmail.com>, clm@...com, 
	dsterba@...e.com, linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [btrfs?] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low! (6)

On Thu, 22 Aug 2024 at 10:57, Josef Bacik <josef@...icpanda.com> wrote:
>
> On Wed, Aug 21, 2024 at 12:45:25PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    5c43d43bad35 Merge branches 'for-next/acpi', 'for-next/mis..
> > git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > console output: https://syzkaller.appspot.com/x/log.txt?x=13471a05980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=c91f83ae59feaa1f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=dfb6eff2a68b42d557d3
> > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > userspace arch: arm64
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10efded5980000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12e94093980000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/cc2dd4be620e/disk-5c43d43b.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/81d40d99ddbf/vmlinux-5c43d43b.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/bc6aed0f2bc5/Image-5c43d43b.gz.xz
> > mounted in repro: https://storage.googleapis.com/syzbot-assets/d55321fffedc/mount_0.gz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+dfb6eff2a68b42d557d3@...kaller.appspotmail.com
> >
> > BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
>
> Can we disable syzbot issues for this specific error?  Btrfs uses lockdep
> annotations for our tree locks, so we _easily_ cross this threshold on the
> default configuration.  Our CI config requires the following settings to get
> lockdep to work longer than two or three tests
>
> CONFIG_LOCKDEP_BITS=20
> CONFIG_LOCKDEP_CHAINS_BITS=20
> CONFIG_LOCKDEP_STACK_TRACE_BITS=19
> CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
> CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
>
> but there's no way to require that in our config (nor do I think we should
> really be able to tbqh).  It makes more sense for syzbot to just ignore this
> particular error as it's not actually a bug.  Thanks,

Hi Josef,

We could bump these values, the last 3 are already this or higher on syzbot.
Do you know if increasing CONFIG_LOCKDEP_BITS and
CONFIG_LOCKDEP_CHAINS_BITS significantly increases memory usage?

Ignoring random bugs on unknown heuristics is really not scalable.
Consider: there are hundreds of kernel subsystems, if each of them
declares a random subset of bugs as not bugs. What's the maintenance
story here? And it's not syzbot specific, any automated and manual
testing will have the same problem.
The only scalable way to mark false reports is to not produce them.