> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> /home/greearb/git/linux.wireless-testing/kernel/sched.c:618 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 1
> 1 lock held by ifup/23517:
> #0: (&rq->lock){-.-.-.}, at: [<
c042f782>] task_fork_fair+0x3b/0x108
>
> stack backtrace:
> Pid: 23517, comm: ifup Not tainted 2.6.36-rc6-wl+ #5
> Call Trace:
> [<
c075e219>] ? printk+0xf/0x16
> [<
c0455842>] lockdep_rcu_dereference+0x74/0x7d
> [<
c0426854>] task_group+0x6d/0x79
> [<
c042686e>] set_task_rq+0xe/0x57
> [<
c042f79e>] task_fork_fair+0x57/0x108
> [<
c042e965>] sched_fork+0x82/0xf9
> [<
c04334b3>] copy_process+0x569/0xe8e
> [<
c0433ef0>] do_fork+0x118/0x262
> [<
c076302f>] ? do_page_fault+0x16a/0x2cf
> [<
c044b80c>] ? up_read+0x16/0x2a
> [<
c04085ae>] sys_clone+0x1b/0x20
> [<
c04030a5>] ptregs_clone+0x15/0x30
> [<
c0402f1c>] ? sysenter_do_call+0x12/0x38
Here a newly created task is having its runqueue assigned. The new task
is not yet on the tasklist, so cannot go away. This is therefore a false
positive, suppress with an RCU read-side critical section.
Reported-by: Ben Greear <greearb@candelatech.com
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Ben Greear <greearb@candelatech.com