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); works as a heavy hammer. -Chris
![]() |