Bug 15510
Summary: | suspicious rcu_dereference_check() usage in scheduler_tick | ||
---|---|---|---|
Product: | Process Management | Reporter: | Christian Casteyde (casteyde.christian) |
Component: | Scheduler | Assignee: | Ingo Molnar (mingo) |
Status: | RESOLVED UNREPRODUCIBLE | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | Yes | Bisected commit-id: |
Description
Christian Casteyde
2010-03-10 18:20:08 UTC
Still present in -rc3, but with a somewhat different call stack: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- net/netfilter/nf_log.c:55 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by swapper/1: #0: (nf_log_mutex){+.+...}, at: [<ffffffff814794f7>] nf_log_register+0x57/0x130 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.34-rc3 #3 Call Trace: [<ffffffff8105e058>] lockdep_rcu_dereference+0xb8/0xc0 [<ffffffff81ac8349>] ? log_tg_init+0x0/0x29 [<ffffffff814795b0>] nf_log_register+0x110/0x130 [<ffffffff81ac8349>] ? log_tg_init+0x0/0x29 [<ffffffff81ac836e>] log_tg_init+0x25/0x29 [<ffffffff810001c7>] do_one_initcall+0x37/0x190 [<ffffffff81a9e5bd>] kernel_init+0xe0/0x16c [<ffffffff815a3152>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81003074>] kernel_thread_helper+0x4/0x10 [<ffffffff815a40fe>] ? restore_args+0x0/0x30 [<ffffffff81a9e4dd>] ? kernel_init+0x0/0x16c [<ffffffff81003070>] ? kernel_thread_helper+0x0/0x10 Maybe it's not the same bug, I dont' know... Update: Still present in -rc4, with the same call stack as in comment #1: =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- net/netfilter/nf_log.c:55 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by swapper/1: #0: (nf_log_mutex){+.+...}, at: [<ffffffff814799e7>] nf_log_register+0x57/0x130 stack backtrace: Pid: 1, comm: swapper Not tainted 2.6.34-rc4 #1 Call Trace: [<ffffffff8105e2e8>] lockdep_rcu_dereference+0xb8/0xc0 [<ffffffff81ac83b9>] ? log_tg_init+0x0/0x29 [<ffffffff81479aa0>] nf_log_register+0x110/0x130 [<ffffffff81ac83b9>] ? log_tg_init+0x0/0x29 [<ffffffff81ac83de>] log_tg_init+0x25/0x29 [<ffffffff810001c7>] do_one_initcall+0x37/0x190 [<ffffffff81a9e5bd>] kernel_init+0xe0/0x16c [<ffffffff815a36e2>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81003074>] kernel_thread_helper+0x4/0x10 [<ffffffff815a467e>] ? restore_args+0x0/0x30 It may be another bug, so maybe I should report it separatly. I'm quite convinced it's not the same bug, I didn't managed to get the initial call stack anymore, but the new warning is always triggered. I'm opening another bug to trace it, and I'm closing this one. |