lkml.org 
[lkml]   [2014]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: lockdep splat in CPU hotplug
On Wed, 22 Oct 2014, Jiri Kosina wrote:

> Still, the lockdep stacktrace is bogus and didn't really help
> understanding this. Any idea why it's wrong?
>
> > ======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 3.18.0-rc1-00069-gc2661b8 #1 Not tainted
> > -------------------------------------------------------
> > do_s2disk/2367 is trying to acquire lock:
> > (cpuidle_lock){+.+.+.}, at: [<ffffffff814916c2>] cpuidle_pause_and_lock+0x12/0x20
> >
> > but task is already holding lock:
> > (cpu_hotplug.lock#2){+.+.+.}, at: [<ffffffff810522ea>] cpu_hotplug_begin+0x4a/0x80
> >
> > which lock already depends on the new lock.
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #1 (cpu_hotplug.lock#2){+.+.+.}:
> > [<ffffffff81099fac>] lock_acquire+0xac/0x130
> > [<ffffffff815b9f2c>] mutex_lock_nested+0x5c/0x3b0
> > [<ffffffff81491892>] cpuidle_pause+0x12/0x30

And the report is clearly bogus here. See:

$ addr2line -a ffffffff81491892 -e vmlinux-3.18.0-rc1-00068-gc2661b8
0xffffffff81491892
/dev/shm/jikos/BUILD/kernel-3.18.0_rc1_00068_gc2661b8/drivers/cpuidle/cpuidle.c:262

where the corresponding lines are

259 void cpuidle_pause(void)
260 {
261 mutex_lock(&cpuidle_lock);
262 cpuidle_uninstall_idle_handler();
263 mutex_unlock(&cpuidle_lock);
264 }

i.e. the RIP saved on stack clearly indicates that we are currently inside
cpuidle_uninstall_idle_handler().

So it's clearly the case that part of the stack (which would probably
point to synchronize_rcu_expedited()) is missing for some reason.

--
Jiri Kosina
SUSE Labs


\
 
 \ /
  Last update: 2014-10-22 14:21    [W:0.177 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site