From: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
To: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"Bart Van Assche" <bvanassche@acm.org>,
<wsd_upstream@mediatek.com>,
Eason-YH Lin <eason-yh.lin@mediatek.com>,
Kobe-CP Wu <kobe-cp.wu@mediatek.com>,
"Jeff-cc Hsu" <jeff-cc.hsu@mediatek.com>,
Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Subject: [PATCH] lockdep: Zap lock classes with debug_locks == false again
Date: Tue, 15 Mar 2022 19:25:21 +0800 [thread overview]
Message-ID: <20220315112521.29093-1-cheng-jui.wang@mediatek.com> (raw)
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
next reply other threads:[~2022-03-15 11:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 11:25 Cheng Jui Wang [this message]
2022-03-15 14:48 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220315112521.29093-1-cheng-jui.wang@mediatek.com \
--to=cheng-jui.wang@mediatek.com \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=eason-yh.lin@mediatek.com \
--cc=jeff-cc.hsu@mediatek.com \
--cc=kobe-cp.wu@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=longman@redhat.com \
--cc=matthias.bgg@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®