linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] lockdep: Zap lock classes with debug_locks == false again
@ 2022-03-15 11:25 Cheng Jui Wang
  2022-03-15 14:48 ` Waiman Long
  0 siblings, 1 reply; 2+ messages in thread
From: Cheng Jui Wang @ 2022-03-15 11:25 UTC (permalink / raw)
  To: linux-kernel, linux-arm-kernel, linux-mediatek
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Matthias Brugger, Bart Van Assche, wsd_upstream,
	Eason-YH Lin, Kobe-CP Wu, Jeff-cc Hsu, Cheng Jui Wang

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 <cheng-jui.wang@mediatek.com>
---
 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. */
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] lockdep: Zap lock classes with debug_locks == false again
  2022-03-15 11:25 [PATCH] lockdep: Zap lock classes with debug_locks == false again Cheng Jui Wang
@ 2022-03-15 14:48 ` Waiman Long
  0 siblings, 0 replies; 2+ messages in thread
From: Waiman Long @ 2022-03-15 14:48 UTC (permalink / raw)
  To: Cheng Jui Wang, linux-kernel, linux-arm-kernel, linux-mediatek
  Cc: Peter Zijlstra, Ingo Molnar, Will Deacon, Boqun Feng,
	Matthias Brugger, Bart Van Assche, wsd_upstream, Eason-YH Lin,
	Kobe-CP Wu, Jeff-cc Hsu

On 3/15/22 07:25, Cheng Jui Wang wrote:
> 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 <cheng-jui.wang@mediatek.com>
> ---
>   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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-03-15 14:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-15 11:25 [PATCH] lockdep: Zap lock classes with debug_locks == false again Cheng Jui Wang
2022-03-15 14:48 ` Waiman Long

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).