lkml.org 
[lkml]   [2022]   [Mar]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] lockdep: Zap lock classes with debug_locks == false again
From
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

\
 
 \ /
  Last update: 2022-03-15 15:49    [W:0.028 / U:3.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site