Message-ID: <20240830160054.GU25962@suse.cz>
Date: Fri, 30 Aug 2024 18:00:54 +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 Fri, Aug 30, 2024 at 05:02:09PM +0200, Dmitry Vyukov wrote:
> On Sat, 24 Aug 2024 at 21:38, David Sterba <dsterba@...e.cz> wrote:
> >
> > 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.
> 
> By "random" I meant that the predicate is some custom English
> sentence, rather than something that can be expressed in the code. So
> on the global kernel scale it's hard/impossible to filter out such
> reports.
> 
> Additional complication here is that the predicate involves knowing
> that exactly system calls triggered this warning, since the warning is
> generic. We don't generally know what exact syscall sequence triggered
> a report. So it would only be possible to ignore "BUG:
> MAX_LOCKDEP_CHAIN_HLOCKS too low" globally, which is not good.
> 
> > > 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.
> 
> I've bumped LOCKDEP parameters in syzbot configs:
> https://github.com/google/syzkaller/commit/f4865e39dd0bcae7e5f3f5d59807d6ac9a8a99ba

LOCKDEP_CHAINS_BITS=20 will improve the situation, thanks.

Powered by blists - more mailing lists