On Tue, Mar 26, 2024 at 10:04 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Tue, Mar 26, 2024 at 09:37:43PM -0700, Paul E. McKenney wrote: > > On Tue, Mar 26, 2024 at 12:53:35PM -0700, Alexei Starovoitov wrote: > > > Hi Paul, > > > > > > syzbot found an interesting false positive deadlock. > > > See below. > > > My understanding is the following: > > > > > > cpu 2: > > > grabs timer_base lock > > > spins on bpf_lpm lock > > > > > > cpu 1: > > > grab rcu krcp lock > > > spins on timer_base lock > > > > > > cpu 0: > > > grab bpf_lpm lock > > > spins on rcu krcp lock > > > > > > bpf_lpm lock can be the same. > > > timer_base lock can also be the same due to timer migration. > > > > > > but rcu krcp lock is always per-cpu, so it cannot be the same lock. > > > Hence it's a false positive, but still interesting. > > > > > > I don't think rcu can tell lockdep that these are different locks. > > > > It might be possible. I will play with this tomorrow, modeling after > > the use of lockdep_set_class_and_name() in rcu_init_one(). I am a bit > > concerned about systems with thousands of CPUs, but it just might be OK. > > Except that each of the resulting separate locks would eventually be > classified as participating in the same type of potential deadlock cycle. :-( That sounds like we have to address it on bpf side, since we're being spammed with syzbot reports of various forms and all of them are about this false positive.
