Quoting Chris Wilson (2020-10-28 17:40:48) > Quoting Chris Wilson (2020-10-27 16:34:53) > > Quoting Peter Zijlstra (2020-10-27 15:45:33) > > > On Tue, Oct 27, 2020 at 01:29:10PM +0000, Chris Wilson wrote: > > > > > > > <4> [304.908891] hm#2, depth: 6 [6], 3425cfea6ff31f7f != > > > > 547d92e9ec2ab9af > > > > <4> [304.908897] WARNING: CPU: 0 PID: 5658 at > > > > kernel/locking/lockdep.c:3679 check_chain_key+0x1a4/0x1f0 > > > > > > Urgh, I don't think I've _ever_ seen that warning trigger. > > > > > > The comments that go with it suggest memory corruption is the most > > > likely trigger of it. Is it easy to trigger? > > > > For the automated CI, yes, the few machines that run that particular HW > > test seem to hit it regularly. I have not yet reproduced it for myself. > > I thought it looked like something kasan would provide some insight for > > and we should get a kasan run through CI over the w/e. I suspect we've > > feed in some garbage and called it a lock. > > I tracked it down to a second invocation of lock_acquire_shared_recursive() > intermingled with some other regular mutexes (in this case ww_mutex). > > We hit this path in validate_chain(): > /* > * Mark recursive read, as we jump over it when > * building dependencies (just like we jump over > * trylock entries): > */ > if (ret == 2) > hlock->read = 2; > > and that is modifying hlock_id() and so the chain-key, after it has > already been computed. > > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c > index 035f81b1cc87..f193f756e1e3 100644 > --- a/kernel/locking/lockdep.c > +++ b/kernel/locking/lockdep.c > @@ -4831,7 +4831,7 @@ static int __lock_acquire(struct lockdep_map *lock, > unsigned int subclass, > if (!validate_chain(curr, hlock, chain_head, chain_key)) > return 0; > > - curr->curr_chain_key = chain_key; > + curr->curr_chain_key = iterate_chain_key(chain_key, hlock_id(hlock)); > curr->lockdep_depth++; > check_chain_key(curr);
No, chain_key should not be chained onto itself again, but I hope it makes the issue clear nevertheless. -Chris
