Messages in this thread | | | Date | Mon, 1 Aug 2011 10:19:00 +0300 | From | Mika Westerberg <> | Subject | Re: [PATCH RESEND] sched: fix false lockdep warning in set_task_cpu() |
| |
On Tue, Jul 26, 2011 at 02:36:01PM +0300, Mika Westerberg wrote: > When we have CONFIG_LOCKDEP enabled we get occasionally following warning > on the system console at boot:
Ping.
Peter, Ingo: any comments on this patch?
> > WARNING: at kernel/sched.c:2204 set_task_cpu+0x1a1/0x390() > Modules linked in: > Pid: 133, comm: mount Not tainted 3.0.0-rc2+ #70 > Call Trace: > [<c104137d>] warn_slowpath_common+0x6d/0xa0 > [<c103d3b1>] ? set_task_cpu+0x1a1/0x390 > [<c103d3b1>] ? set_task_cpu+0x1a1/0x390 > [<c10413cd>] warn_slowpath_null+0x1d/0x20 > [<c103d3b1>] set_task_cpu+0x1a1/0x390 > [<c103e0a7>] try_to_wake_up+0x127/0x250 > [<c103e1db>] default_wake_function+0xb/0x10 > [<c106290e>] autoremove_wake_function+0x1e/0x50 > [<c102a2b0>] __wake_up_common+0x40/0x70 > [<c102f2d7>] __wake_up+0x37/0x50 > [<c12d36c0>] ? serial_m3110_enable_ms+0x10/0x10 > [<c12d3715>] serial_m3110_con_write+0x55/0x60 > [<c1041575>] __call_console_drivers+0x75/0x90 > [<c10415d9>] _call_console_drivers+0x49/0x80 > [<c1041baa>] console_unlock+0xca/0x1f0 > [<c10420ef>] vprintk+0x18f/0x4f0 > [<c10787cb>] ? trace_hardirqs_on+0xb/0x10 > [<c107985e>] ? lockdep_init_map+0x4e/0x4c0 > [<c10787cb>] ? trace_hardirqs_on+0xb/0x10 > [<c14928a3>] printk+0x18/0x1a > [<c115dd4e>] ext3_msg+0x3e/0x40 > [<c116046a>] ext3_fill_super+0x16ba/0x1960 > [<c11478b8>] ? disk_name+0x88/0xc0 > [<c10fa88d>] mount_bdev+0x16d/0x1b0 > [<c10ed667>] ? __kmalloc_track_caller+0xf7/0x280 > [<c1112021>] ? alloc_vfsmnt+0x81/0x140 > [<c115d20a>] ext3_mount+0x1a/0x20 > [<c115edb0>] ? ext3_clear_journal_err+0xa0/0xa0 > [<c10f95dc>] mount_fs+0x1c/0xc0 > [<c10d763a>] ? __alloc_percpu+0xa/0x10 > [<c111203b>] ? alloc_vfsmnt+0x9b/0x140 > [<c1112896>] vfs_kern_mount+0x46/0xa0 > [<c1113609>] do_kern_mount+0x39/0xd0 > [<c1114087>] do_mount+0x2c7/0x680 > [<c10d31f9>] ? strndup_user+0x49/0x60 > [<c11144a6>] sys_mount+0x66/0xa0 > [<c14976d0>] sysenter_do_call+0x12/0x36 > > This is due the fact that printk() disables lockdep before the output is > passed to the actual console driver. If the console driver happens to call > some functions which eventually calls set_task_cpu() we end up failing the > following test: > > WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) || > lockdep_is_held(&task_rq(p)->lock))); > > This is because lockdep_is_held() returns 0 if lockdep is temporarily > disabled. > > So we check whether lockdep is enabled and only then validate the locks. > > Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> > Cc: Peter Zijlstra <peterz@infradead.org> > Cc: Ingo Molnar <mingo@elte.hu> > --- > kernel/sched.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/kernel/sched.c b/kernel/sched.c > index 9769c75..1177f81 100644 > --- a/kernel/sched.c > +++ b/kernel/sched.c > @@ -2211,8 +2211,9 @@ void set_task_cpu(struct task_struct *p, unsigned int new_cpu) > * Furthermore, all task_rq users should acquire both locks, see > * task_rq_lock(). > */ > - WARN_ON_ONCE(debug_locks && !(lockdep_is_held(&p->pi_lock) || > - lockdep_is_held(&task_rq(p)->lock))); > + WARN_ON_ONCE(debug_locks && !current->lockdep_recursion && > + !(lockdep_is_held(&p->pi_lock) || > + lockdep_is_held(&task_rq(p)->lock))); > #endif > #endif > > -- > 1.7.5.4
| |