* [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in get_kprobe()
@ 2019-12-20 12:49 John Garry
2019-12-20 18:58 ` Masami Hiramatsu
0 siblings, 1 reply; 2+ messages in thread
From: John Garry @ 2019-12-20 12:49 UTC (permalink / raw)
To: naveen.n.rao, anil.s.keshavamurthy, davem, mhiramat
Cc: linux-kernel, paulmck, anders.roxell, John Garry
With CONFIG_PROVE_RCU_LIST set, we may get the following WARN in the
test code:
Kprobe smoke test: started
=============================
WARNING: suspicious RCU usage
5.5.0-rc1-00013-ge15bd404ed10-dirty #802 Not tainted
-----------------------------
kernel/kprobes.c:329 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by swapper/0/1:
#0: ffff800011bf3648 (kprobe_mutex){+.+.}, at: register_kprobe+0x94/0x5a0
stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc1-00013-ge15bd404ed10-dirty #802
Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
Call trace:
dump_backtrace+0x0/0x1a0
show_stack+0x14/0x20
dump_stack+0xe8/0x150
lockdep_rcu_suspicious+0xcc/0x110
get_kprobe+0xb8/0xc0
__get_valid_kprobe+0x18/0xc8
register_kprobe+0x9c/0x5a0
init_test_probes+0x80/0x400
init_kprobes+0x13c/0x154
do_one_initcall+0x88/0x428
kernel_init_freeable+0x21c/0x2c4
kernel_init+0x10/0x108
ret_from_fork+0x10/0x18
Kprobe smoke test: passed successfully
The code comment tells us the locking requirements:
/*
* This routine is called either:
* - under the kprobe_mutex - during kprobe_[un]register()
* OR
* - with preemption disabled - from arch/xxx/kernel/kprobes.c
*/
struct kprobe *get_kprobe(void *addr)
{
struct hlist_head *head;
struct kprobe *p;
head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
hlist_for_each_entry_rcu(p, head, hlist,
And we have the kprobe_mutex held in the path of concern, so add a
RCU list traversal check condition for this.
Signed-off-by: John Garry <john.garry@huawei.com>
---
I sent as an RFC as I am not 100% certain that this is the right fix.
It does solve my WARN.
I also assume __get_valid_kprobe() will require a similar change for
similar reason.
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 53534aa258a6..908abdac77f1 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -326,7 +326,8 @@ struct kprobe *get_kprobe(void *addr)
struct kprobe *p;
head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
- hlist_for_each_entry_rcu(p, head, hlist) {
+ hlist_for_each_entry_rcu(p, head, hlist,
+ mutex_is_locked(&kprobe_mutex)) {
if (p->addr == addr)
return p;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in get_kprobe()
2019-12-20 12:49 [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in get_kprobe() John Garry
@ 2019-12-20 18:58 ` Masami Hiramatsu
0 siblings, 0 replies; 2+ messages in thread
From: Masami Hiramatsu @ 2019-12-20 18:58 UTC (permalink / raw)
To: John Garry
Cc: naveen.n.rao, anil.s.keshavamurthy, davem, linux-kernel, paulmck,
anders.roxell
Hi John,
Thanks for your work. Actually, I already sent the same fix 2 weeks ago.
https://lore.kernel.org/lkml/157535316659.16485.11817291759382261088.stgit@devnote2/
Thank you,
On Fri, 20 Dec 2019 20:49:51 +0800
John Garry <john.garry@huawei.com> wrote:
> With CONFIG_PROVE_RCU_LIST set, we may get the following WARN in the
> test code:
>
> Kprobe smoke test: started
>
> =============================
> WARNING: suspicious RCU usage
> 5.5.0-rc1-00013-ge15bd404ed10-dirty #802 Not tainted
> -----------------------------
> kernel/kprobes.c:329 RCU-list traversed in non-reader section!!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 2, debug_locks = 1
> 1 lock held by swapper/0/1:
> #0: ffff800011bf3648 (kprobe_mutex){+.+.}, at: register_kprobe+0x94/0x5a0
>
> stack backtrace:
> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc1-00013-ge15bd404ed10-dirty #802
> Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018
> Call trace:
> dump_backtrace+0x0/0x1a0
> show_stack+0x14/0x20
> dump_stack+0xe8/0x150
> lockdep_rcu_suspicious+0xcc/0x110
> get_kprobe+0xb8/0xc0
> __get_valid_kprobe+0x18/0xc8
> register_kprobe+0x9c/0x5a0
> init_test_probes+0x80/0x400
> init_kprobes+0x13c/0x154
> do_one_initcall+0x88/0x428
> kernel_init_freeable+0x21c/0x2c4
> kernel_init+0x10/0x108
> ret_from_fork+0x10/0x18
> Kprobe smoke test: passed successfully
>
> The code comment tells us the locking requirements:
>
> /*
> * This routine is called either:
> * - under the kprobe_mutex - during kprobe_[un]register()
> * OR
> * - with preemption disabled - from arch/xxx/kernel/kprobes.c
> */
> struct kprobe *get_kprobe(void *addr)
> {
> struct hlist_head *head;
> struct kprobe *p;
>
> head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
> hlist_for_each_entry_rcu(p, head, hlist,
>
> And we have the kprobe_mutex held in the path of concern, so add a
> RCU list traversal check condition for this.
>
> Signed-off-by: John Garry <john.garry@huawei.com>
> ---
> I sent as an RFC as I am not 100% certain that this is the right fix.
> It does solve my WARN.
>
> I also assume __get_valid_kprobe() will require a similar change for
> similar reason.
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 53534aa258a6..908abdac77f1 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -326,7 +326,8 @@ struct kprobe *get_kprobe(void *addr)
> struct kprobe *p;
>
> head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
> - hlist_for_each_entry_rcu(p, head, hlist) {
> + hlist_for_each_entry_rcu(p, head, hlist,
> + mutex_is_locked(&kprobe_mutex)) {
> if (p->addr == addr)
> return p;
> }
> --
> 2.17.1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-12-20 18:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-20 12:49 [RFC PATCH] kprobes: Fix suspicious RCU usage WARN in get_kprobe() John Garry
2019-12-20 18:58 ` Masami Hiramatsu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.