Messages in this thread | | | Date | Wed, 22 Oct 2014 13:39:56 +0200 (CEST) | From | Jiri Kosina <> | Subject | Re: 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
| |