[RFC] kprobes: Fix suspicious RCU usage WARN in get_kprobe()

Message ID 1576846191-18801-1-git-send-email-john.garry@huawei.com
State New
Headers show
Series
  • [RFC] kprobes: Fix suspicious RCU usage WARN in get_kprobe()
Related show

Commit Message

John Garry Dec. 20, 2019, 12:49 p.m.
With CONFIG_PROVE_RCU_LIST set, we may get the following WARN in the
test code:

Kprobe smoke test: started

-- 
2.17.1

Comments

Masami Hiramatsu Dec. 20, 2019, 6:58 p.m. | #1
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>

Patch

=============================
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;
 	}