* 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