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: <20240824193835.GN25962@suse.cz>
Date: Sat, 24 Aug 2024 21:38:35 +0200
From: David Sterba <dsterba@...e.cz>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Josef Bacik <josef@...icpanda.com>,
	syzkaller <syzkaller@...glegroups.com>,
	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, Aug 22, 2024 at 02:05:01PM +0200, Dmitry Vyukov wrote:
> > > 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.

This is not a random bug. The warning has been reported many times, it
does not point to a specific problem in code that uses lockdep but
rather some defficiency in the lockdep mechanism itself.

> Consider: there are hundreds of kernel subsystems, if each of them
> declares a random subset of bugs as not bugs.

"If each of them", no this won't happen. Or, if you add this one and
reject the others you'll still make people happy.

> What's the maintenance
> story here? And it's not syzbot specific, any automated and manual
> testing will have the same problem.

Yes this does not avoid reports but at least it won't be a syzbot report
that somebody thinks is worth time. Everybody else will be told "ignore"
or poitned to documentation or the report ignored completely
(https://btrfs.readthedocs.io/en/latest/dev/Development-notes.html#bug-max-lockdep-chain-hlocks-too-low).

> The only scalable way to mark false reports is to not produce them.

In an ideal case yes. So far we have only the workaround with increasing
the config value (which makes sense on a distro config), otherwise I
remembet locking guys to suggest some fix but I can't find it now in the
numerous reports.