linux-kernel - Re: INFO: suspicious rcu_dereference_check() usage - kernel/pid.c:419 invoked rcu_dereference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 7 Nov 2010 10:20:28 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Greg Thelen <gthelen@...gle.com>
Cc:	Oleg Nesterov <oleg@...sign.ru>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: INFO: suspicious rcu_dereference_check() usage -
 kernel/pid.c:419 invoked rcu_dereference_check() without protection!

On Tue, Oct 12, 2010 at 12:08:46AM -0700, Greg Thelen wrote:
> I observe a failing rcu_dereference_check() in linux-next (found in
> mmotm-2010-10-07-14-08).  An extra rcu assertion in
> find_task_by_pid_ns() was added by:
>   commit 4221a9918e38b7494cee341dda7b7b4bb8c04bde
>   Author: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
>   Date:   Sat Jun 26 01:08:19 2010 +0900
>   
>       Add RCU check for find_task_by_vpid().
> 
> This extra assertion causes a rcu_dereference_check() failure during
> boot in 512 MIB VM.  I would be happy to get out proposed patches to
> this issue.  My config includes:
>   CONFIG_PREEMPT=y
>   CONFIG_LOCKDEP=y
>   CONFIG_PROVE_LOCKING=y
>   CONFIG_PROVE_RCU=y
> 
> The console error:
> 
> Begin: Running /scripts/local-bottom ...
> Done.
> Done.
> Begin: Running /scripts/init-bottom ...
> Done.
> [    3.394348]
> [    3.394349] ===================================================
> [    3.395162] [ INFO: suspicious rcu_dereference_check() usage. ]
> [    3.395786] ---------------------------------------------------
> [    3.396452] kernel/pid.c:419 invoked rcu_dereference_check() without protection!
> [    3.397483]
> [    3.397484] other info that might help us debug this:
> [    3.397485]
> [    3.398363]
> [    3.398364] rcu_scheduler_active = 1, debug_locks = 0
> [    3.399073] 1 lock held by ureadahead/1438:
> [    3.399515]  #0:  (tasklist_lock){.+.+..}, at: [<ffffffff811c1d1a>] sys_ioprio_set+0x8a/0x3f0
> [    3.400500]
> [    3.400501] stack backtrace:
> [    3.401036] Pid: 1438, comm: ureadahead Not tainted 2.6.36-dbg-DEV #10
> [    3.401717] Call Trace:
> [    3.401996]  [<ffffffff810c720b>] lockdep_rcu_dereference+0xbb/0xc0
> [    3.402742]  [<ffffffff810aebb1>] find_task_by_pid_ns+0x81/0x90
> [    3.403445]  [<ffffffff810aebe2>] find_task_by_vpid+0x22/0x30
> [    3.404146]  [<ffffffff811c2074>] sys_ioprio_set+0x3e4/0x3f0
> [    3.404756]  [<ffffffff815c5919>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [    3.405455]  [<ffffffff8104331b>] system_call_fastpath+0x16/0x1b
> 
> 
> ioprio_set() contains a comment warning against of usage of
> rcu_read_lock() to avoid this warning:
> 	/*
> 	 * We want IOPRIO_WHO_PGRP/IOPRIO_WHO_USER to be "atomic",
> 	 * so we can't use rcu_read_lock(). See re-copy of ->ioprio
> 	 * in copy_process().
> 	 */
> 
> So I'm not sure what the best fix is.

I must defer to Oleg, who wrote the comment.  But please see below.

> Also I see that sys_ioprio_get() has a similar problem that might be
> addressed with:

There is a patch from Sergey Senozhatsky currently in -mm that encloses
a subset of this code (both ioprio_set and ioprio_get) in rcu_read_lock()
and rcu_read_unlock(), see http://lkml.org/lkml/2010/10/29/168.

							Thanx, Paul

> diff --git a/fs/ioprio.c b/fs/ioprio.c
> index 748cfb9..02eed30 100644
> --- a/fs/ioprio.c
> +++ b/fs/ioprio.c
> @@ -197,6 +197,7 @@ SYSCALL_DEFINE2(ioprio_get, int, which, int, who)
>  	int ret = -ESRCH;
>  	int tmpio;
> 
> +	rcu_read_lock();
>  	read_lock(&tasklist_lock);
>  	switch (which) {
>  		case IOPRIO_WHO_PROCESS:
> @@ -251,5 +252,6 @@ SYSCALL_DEFINE2(ioprio_get, int, which, int, who)
>  	}
> 
>  	read_unlock(&tasklist_lock);
> +	rcu_read_unlock();
>  	return ret;
>  }
> 
> sys_ioprio_get() didn't have an explicit warning against usage of
> rcu_read_lock(), but that doesn't mean this is a good patch.
> 
> --
> Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/