> On May 14, 2020, at 9:33 AM, Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Thu, May 14, 2020 at 08:31:13AM -0400, Qian Cai wrote: >> >> >>> On May 14, 2020, at 8:25 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: >>> >>> Hi Paul, >>> >>> This patch in the rcu tree >>> >>> d13fee049fa8 ("Default enable RCU list lockdep debugging with PROVE_RCU") >>> >>> is causing whack-a-mole in the syzbot testing of linux-next. Because >>> they always do a debug build of linux-next, no testing is getting done. :-( >>> >>> Can we find another way to find all the bugs that are being discovered >>> (very slowly)? >> >> Alternatively, could syzbot to use PROVE_RCU=n temporarily because it can’t keep up with it? I personally found PROVE_RCU_LIST=y is still useful for my linux-next testing, and don’t want to lose that coverage overnight. > > The problem is that PROVE_RCU is exactly PROVE_LOCKING, and asking people > to test without PROVE_LOCKING is a no-go in my opinion. But of course > on the other hand if there is no testing of RCU list lockdep debugging, > those issues will never be found, let alone fixed. > > One approach would be to do as Stephen asks (either remove d13fee049fa8 > or pull it out of -next) and have testers force-enable the RCU list > lockdep debugging. > > Would that work for you? Alternatively, how about having PROVE_RCU_LIST=n if DEBUG_AID_FOR_SYZBOT since it is only syzbot can’t keep up with it?