Message-ID: <CACT4Y+bsEPHkzofGZPHkhpj1jnGRwFmqR-scJGX0EXAZLe-Zng@mail.gmail.com>
Date: Fri, 30 Aug 2024 17:02:09 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: dsterba@...e.cz
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 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

So this can be closed:

#syz invalid

Powered by blists - more mailing lists