Messages in this thread | | | Date | Wed, 22 Oct 2014 14:09:43 -0700 | From | "Paul E. McKenney" <> | Subject | Re: lockdep splat in CPU hotplug |
| |
On Wed, Oct 22, 2014 at 10:57:25PM +0200, Jiri Kosina wrote: > On Wed, 22 Oct 2014, Paul E. McKenney wrote: > > > rcu: More on deadlock between CPU hotplug and expedited grace periods > > > > Commit dd56af42bd82 (rcu: Eliminate deadlock between CPU hotplug and > > expedited grace periods) was incomplete. Although it did eliminate > > deadlocks involving synchronize_sched_expedited()'s acquisition of > > cpu_hotplug.lock via get_online_cpus(), it did nothing about the similar > > deadlock involving acquisition of this same lock via put_online_cpus(). > > This deadlock became apparent with testing involving hibernation. > > > > This commit therefore changes put_online_cpus() acquisition of this lock > > to be conditional, and increments a new cpu_hotplug.puts_pending field > > in case of acquisition failure. Then cpu_hotplug_begin() checks for this > > new field being non-zero, and applies any changes to cpu_hotplug.refcount. > > > > Yes, this works. FWIW, please feel free to add > > Reported-and-tested-by: Jiri Kosina <jkosina@suse.cz> > > once merging it.
Done, and thank you for both the bug report and the testing!
> Why lockdep produced such an incomplete stacktrace still remains > unexplained.
On that, I must defer to people more familiar with stack frames.
Thanx, Paul
> Thanks, > > -- > Jiri Kosina > SUSE Labs >
| |