Re: [PATCH] lockdep: Zap lock classes with debug_locks == false again

From
Waiman Long <longman@redhat.com>
Date
2022-03-15 14:48:38
Also in
linux-mediatek, lkml
Reply to
Cheng Jui Wang, 2022-03-15
On 3/15/22 07:25, Cheng Jui Wang wrote:
quoted hunk ↗ jump to hunk
If a lock_class_key has been registered but lockdep_unregister_key() is
called with debug_locks == false. The lockdep_unregister_key() will not
unregister the key and just return without error.
Users may assume lockdep_unregister_key() always succeed and free the
lock_class_key even if it is still remained in lockdep structures.

Which lead to following crash when 'cat /proc/lockdep' after
debug_locks == false:

==================================================================
BUG: KASAN: invalid-access in string+0x50/0x10c
Read at addr f2ffff81ac61c880 by ...
Pointer tag: [f2], memory tag: [fb]
...
Call trace:
  dump_backtrace.cfi_jt+0x0/0x8
  show_stack+0x1c/0x2c
  dump_stack_lvl+0xd8/0x16c
  print_address_description+0x90/0x2e8
  __kasan_report+0x144/0x224
  kasan_report+0x50/0xa0
  __do_kernel_fault+0xf4/0x2a8
  do_bad_area+0x34/0xf8
  do_tag_check_fault+0x24/0x38
  do_mem_abort+0x68/0x168
  el1_abort+0x4c/0x74
  el1_sync_handler+0x4c/0x8c
  el1_sync+0x8c/0x140
  string+0x50/0x10c
  vsnprintf+0x468/0x69c
  seq_printf+0x8c/0xd8
  print_name+0x64/0xf4
  l_show+0x1a8/0x278
  seq_read_iter+0x3cc/0x5fc
  proc_reg_read_iter+0xdc/0x1d4
  vfs_read+0x2e0/0x354
  ksys_read+0x7c/0xec
  __arm64_sys_read+0x20/0x30
  el0_svc_common.llvm.8008154191216078041+0xd8/0x20c
  do_el0_svc+0x28/0xa0
  el0_svc+0x24/0x38
  el0_sync_handler+0x88/0xec
  el0_sync+0x1b4/0x1c0

...
==================================================================

Allow lockdep_unregister_key to zap lock classes with
debug_locks == false again.
Remove the WARN_ON_ONCE(!found) and only zap lock classes when the key
can be found.

Fixes: 8b39adbee805 ("locking/lockdep: Make lockdep_unregister_key() honor 'debug_locks' again")
Signed-off-by: Cheng Jui Wang <redacted>
---
  kernel/locking/lockdep.c | 13 ++++++-------
  1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index f8a0212189ca..90dadecb2577 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -6305,8 +6305,7 @@ void lockdep_unregister_key(struct lock_class_key *key)
  		return;
  
  	raw_local_irq_save(flags);
-	if (!graph_lock())
-		goto out_irq;
+	lockdep_lock();
  
  	pf = get_pending_free();
  	hlist_for_each_entry_rcu(k, hash_head, hash_entry) {
@@ -6316,11 +6315,11 @@ void lockdep_unregister_key(struct lock_class_key *key)
  			break;
  		}
  	}
-	WARN_ON_ONCE(!found);
-	__lockdep_free_key_range(pf, key, 1);
-	call_rcu_zapped(pf);
-	graph_unlock();
-out_irq:
+	if (found) {
+		__lockdep_free_key_range(pf, key, 1);
+		call_rcu_zapped(pf);
+	}
+	lockdep_unlock();
  	raw_local_irq_restore(flags);
  
  	/* Wait until is_dynamic_key() has finished accessing k->hash_entry. */
Thanks for the patch.

However, this is a known problem and had been fixed by commit 61cc4534b655 ("locking/lockdep: Avoid potential access of invalid memory in lock_class") in the tip tree. It will get merged into v5.18 kernel.

Cheers,
Longman


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Thread (2 messages) 2 messages, 2 authors, last reply 2022-03-15
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help