* Re: 2.6.35 - INFO: kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
[not found] <AANLkTimULDfJ9n2XxNmtq8yUcNRfAywHpiDDXRKtev10@mail.gmail.com>
@ 2010-08-09 17:27 ` Paul E. McKenney
2010-08-16 22:37 ` Miles Lane
0 siblings, 1 reply; 3+ messages in thread
From: Paul E. McKenney @ 2010-08-09 17:27 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, dhowells
On Tue, Aug 03, 2010 at 11:20:58PM -0400, Miles Lane wrote:
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
> rcu_scheduler_active = 1, debug_locks = 1
> 2 locks held by init/1:
> #0: (tasklist_lock){.+.+..}, at: [<ffffffff81045ca8>] do_wait+0xa9/0x1fa
> #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff810457e8>]
> wait_consider_task+0x5e1/0x9f8
>
> stack backtrace:
> Pid: 1, comm: init Not tainted 2.6.35 #15
> Call Trace:
> [<ffffffff8106759c>] lockdep_rcu_dereference+0x9d/0xa6
> [<ffffffff81045877>] wait_consider_task+0x670/0x9f8
> [<ffffffff81045d14>] do_wait+0x115/0x1fa
> [<ffffffff81045f41>] sys_waitid+0x7f/0x178
> [<ffffffff81009cba>] ? sysret_check+0x2e/0x69
> [<ffffffff8104454e>] ? child_wait_callback+0x0/0x53
> [<ffffffff81009c82>] system_call_fastpath+0x16/0x1b
This one is interesting. The ->sighand->siglock is held, but the
rcu_dereference_check() check condition requires that either the
task is dead or that we are in an RCU read-side critical section.
The comment preceding the call to __task_cred() claims that we
"don't need the RCU readlock here as we're holding a spinlock."
This comment dates back to 2008, so might be obsolete.
David, should we enclose the __task_cred() in wait_task_stopped()
with rcu_read_lock()? Or would it be better to add a check to
__task_cred() checking for ->sighand->siglock? Or do we need to
do something else entirely? ;-)
Thanx, Paul
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: 2.6.35 - INFO: kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
2010-08-09 17:27 ` 2.6.35 - INFO: kernel/exit.c:1387 invoked rcu_dereference_check() without protection! Paul E. McKenney
@ 2010-08-16 22:37 ` Miles Lane
2010-08-16 22:57 ` Paul E. McKenney
0 siblings, 1 reply; 3+ messages in thread
From: Miles Lane @ 2010-08-16 22:37 UTC (permalink / raw)
To: paulmck; +Cc: LKML, dhowells
Hi Paul and friends,
Now in 2.6.36-rc1:
[ 7.295797] ===================================================
[ 7.295801] [ INFO: suspicious rcu_dereference_check() usage. ]
[ 7.295805] ---------------------------------------------------
[ 7.295810] kernel/exit.c:1390 invoked rcu_dereference_check()
without protection!
[ 7.295813]
[ 7.295814] other info that might help us debug this:
[ 7.295816]
[ 7.295819]
[ 7.295820] rcu_scheduler_active = 1, debug_locks = 1
[ 7.295825] 2 locks held by init/1:
[ 7.295827] #0: (tasklist_lock){.+.+..}, at: [<ffffffff8103e31c>]
do_wait+0xa5/0x1fa
[ 7.295843] #1: (&(&sighand->siglock)->rlock){......}, at:
[<ffffffff8103de60>] wait_consider_task+0x5e1/0x9f8
[ 7.295854]
[ 7.295855] stack backtrace:
[ 7.295860] Pid: 1, comm: init Not tainted 2.6.36-rc1 #3
[ 7.295864] Call Trace:
[ 7.295872] [<ffffffff81061999>] lockdep_rcu_dereference+0x9d/0xa6
[ 7.295878] [<ffffffff8103deef>] wait_consider_task+0x670/0x9f8
[ 7.295884] [<ffffffff8103e388>] do_wait+0x111/0x1fa
[ 7.295890] [<ffffffff8103e5b9>] sys_waitid+0x7f/0x178
[ 7.295898] [<ffffffff81002a5c>] ? sysret_check+0x27/0x62
[ 7.295904] [<ffffffff8103cbc6>] ? child_wait_callback+0x0/0x53
[ 7.295911] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
On Mon, Aug 9, 2010 at 10:27 AM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Tue, Aug 03, 2010 at 11:20:58PM -0400, Miles Lane wrote:
>> [ INFO: suspicious rcu_dereference_check() usage. ]
>> ---------------------------------------------------
>> kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
>>
>> other info that might help us debug this:
>>
>> rcu_scheduler_active = 1, debug_locks = 1
>> 2 locks held by init/1:
>> #0: (tasklist_lock){.+.+..}, at: [<ffffffff81045ca8>] do_wait+0xa9/0x1fa
>> #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff810457e8>]
>> wait_consider_task+0x5e1/0x9f8
>>
>> stack backtrace:
>> Pid: 1, comm: init Not tainted 2.6.35 #15
>> Call Trace:
>> [<ffffffff8106759c>] lockdep_rcu_dereference+0x9d/0xa6
>> [<ffffffff81045877>] wait_consider_task+0x670/0x9f8
>> [<ffffffff81045d14>] do_wait+0x115/0x1fa
>> [<ffffffff81045f41>] sys_waitid+0x7f/0x178
>> [<ffffffff81009cba>] ? sysret_check+0x2e/0x69
>> [<ffffffff8104454e>] ? child_wait_callback+0x0/0x53
>> [<ffffffff81009c82>] system_call_fastpath+0x16/0x1b
>
> This one is interesting. The ->sighand->siglock is held, but the
> rcu_dereference_check() check condition requires that either the
> task is dead or that we are in an RCU read-side critical section.
> The comment preceding the call to __task_cred() claims that we
> "don't need the RCU readlock here as we're holding a spinlock."
> This comment dates back to 2008, so might be obsolete.
>
> David, should we enclose the __task_cred() in wait_task_stopped()
> with rcu_read_lock()? Or would it be better to add a check to
> __task_cred() checking for ->sighand->siglock? Or do we need to
> do something else entirely? ;-)
>
> Thanx, Paul
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: 2.6.35 - INFO: kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
2010-08-16 22:37 ` Miles Lane
@ 2010-08-16 22:57 ` Paul E. McKenney
0 siblings, 0 replies; 3+ messages in thread
From: Paul E. McKenney @ 2010-08-16 22:57 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, dhowells
On Mon, Aug 16, 2010 at 03:37:30PM -0700, Miles Lane wrote:
> Hi Paul and friends,
>
> Now in 2.6.36-rc1:
Hello, Miles!
Could you please try David Howells's patch? It may be found at:
http://lkml.org/lkml/2010/8/16/333
It should address this one.
Thanx, Paul
> [ 7.295797] ===================================================
> [ 7.295801] [ INFO: suspicious rcu_dereference_check() usage. ]
> [ 7.295805] ---------------------------------------------------
> [ 7.295810] kernel/exit.c:1390 invoked rcu_dereference_check()
> without protection!
> [ 7.295813]
> [ 7.295814] other info that might help us debug this:
> [ 7.295816]
> [ 7.295819]
> [ 7.295820] rcu_scheduler_active = 1, debug_locks = 1
> [ 7.295825] 2 locks held by init/1:
> [ 7.295827] #0: (tasklist_lock){.+.+..}, at: [<ffffffff8103e31c>]
> do_wait+0xa5/0x1fa
> [ 7.295843] #1: (&(&sighand->siglock)->rlock){......}, at:
> [<ffffffff8103de60>] wait_consider_task+0x5e1/0x9f8
> [ 7.295854]
> [ 7.295855] stack backtrace:
> [ 7.295860] Pid: 1, comm: init Not tainted 2.6.36-rc1 #3
> [ 7.295864] Call Trace:
> [ 7.295872] [<ffffffff81061999>] lockdep_rcu_dereference+0x9d/0xa6
> [ 7.295878] [<ffffffff8103deef>] wait_consider_task+0x670/0x9f8
> [ 7.295884] [<ffffffff8103e388>] do_wait+0x111/0x1fa
> [ 7.295890] [<ffffffff8103e5b9>] sys_waitid+0x7f/0x178
> [ 7.295898] [<ffffffff81002a5c>] ? sysret_check+0x27/0x62
> [ 7.295904] [<ffffffff8103cbc6>] ? child_wait_callback+0x0/0x53
> [ 7.295911] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b
>
>
> On Mon, Aug 9, 2010 at 10:27 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Tue, Aug 03, 2010 at 11:20:58PM -0400, Miles Lane wrote:
> >> [ INFO: suspicious rcu_dereference_check() usage. ]
> >> ---------------------------------------------------
> >> kernel/exit.c:1387 invoked rcu_dereference_check() without protection!
> >>
> >> other info that might help us debug this:
> >>
> >> rcu_scheduler_active = 1, debug_locks = 1
> >> 2 locks held by init/1:
> >> #0: (tasklist_lock){.+.+..}, at: [<ffffffff81045ca8>] do_wait+0xa9/0x1fa
> >> #1: (&(&sighand->siglock)->rlock){......}, at: [<ffffffff810457e8>]
> >> wait_consider_task+0x5e1/0x9f8
> >>
> >> stack backtrace:
> >> Pid: 1, comm: init Not tainted 2.6.35 #15
> >> Call Trace:
> >> [<ffffffff8106759c>] lockdep_rcu_dereference+0x9d/0xa6
> >> [<ffffffff81045877>] wait_consider_task+0x670/0x9f8
> >> [<ffffffff81045d14>] do_wait+0x115/0x1fa
> >> [<ffffffff81045f41>] sys_waitid+0x7f/0x178
> >> [<ffffffff81009cba>] ? sysret_check+0x2e/0x69
> >> [<ffffffff8104454e>] ? child_wait_callback+0x0/0x53
> >> [<ffffffff81009c82>] system_call_fastpath+0x16/0x1b
> >
> > This one is interesting. The ->sighand->siglock is held, but the
> > rcu_dereference_check() check condition requires that either the
> > task is dead or that we are in an RCU read-side critical section.
> > The comment preceding the call to __task_cred() claims that we
> > "don't need the RCU readlock here as we're holding a spinlock."
> > This comment dates back to 2008, so might be obsolete.
> >
> > David, should we enclose the __task_cred() in wait_task_stopped()
> > with rcu_read_lock()? Or would it be better to add a check to
> > __task_cred() checking for ->sighand->siglock? Or do we need to
> > do something else entirely? ;-)
> >
> > Thanx, Paul
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-08-16 22:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTimULDfJ9n2XxNmtq8yUcNRfAywHpiDDXRKtev10@mail.gmail.com>
2010-08-09 17:27 ` 2.6.35 - INFO: kernel/exit.c:1387 invoked rcu_dereference_check() without protection! Paul E. McKenney
2010-08-16 22:37 ` Miles Lane
2010-08-16 22:57 ` Paul E. McKenney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox