On Tue, 21 Oct 2014, Paul E. McKenney wrote: > > Looks like this indeed is something that lockdep *should* report (*), > > although I would be suprised that stack unwinder would be so confused > > by this -- there is no way for synchronize_sched_expedited() to be > > inlined all the way to cpuidle_pause(). > > I think that if synchronize_sched_expedited() was in fact called, it > had already returned by the time we hit this problem. But I must confess > that I am not seeing how cpuidle_uninstall_idle_handler() gets to > synchronize_rcu().
Umm, it directly calls it? :-) void cpuidle_uninstall_idle_handler(void) { if (enabled_devices) { initialized = 0; wake_up_all_idle_cpus(); } /* * Make sure external observers (such as the scheduler) * are done looking at pointed idle states. */ synchronize_rcu(); } > > (*) there are multiple places where cpu_hotplug.lock -> cpuidle_lock lock > > dependency is assumed. The patch that Dave pointed out adds > > cpuidle_lock -> cpu_hotplug.lock dependency. > > > > Still not clear whether this is what's happening here ... anyway, adding > > Paul to CC. > > Hmmm... > > Both cpuidle_pause() and cpuidle_pause_and_lock() acquire cpuidle_lock, > and are at the top of both stacks. Which was the original confusion. ;-) Yup, they are, but lockdep is complaining about cpuidle_pause() acquiring cpu_hotplug.lock ... Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/