summaryrefslogtreecommitdiff
path: root/init
diff options
context:
space:
mode:
authorPaul E. McKenney <paulmck@linux.vnet.ibm.com>2012-10-07 08:36:12 -0700
committerPaul E. McKenney <paulmck@linux.vnet.ibm.com>2012-10-08 09:06:38 -0700
commita4fbe35a124526e6759be07bd9c7ea796ba1e00d (patch)
treecb5c5a1608fcff588ed9a204ea67d5891adb18fb /init
parentcb349ca95407cbc11424d5e9fc7c8e700709041b (diff)
downloadlinux-3.10-a4fbe35a124526e6759be07bd9c7ea796ba1e00d.tar.gz
linux-3.10-a4fbe35a124526e6759be07bd9c7ea796ba1e00d.tar.bz2
linux-3.10-a4fbe35a124526e6759be07bd9c7ea796ba1e00d.zip
rcu: Grace-period initialization excludes only RCU notifier
Kirill noted the following deadlock cycle on shutdown involving padata: > With commit 755609a9087fa983f567dc5452b2fa7b089b591f I've got deadlock on > poweroff. > > It guess it happens because of race for cpu_hotplug.lock: > > CPU A CPU B > disable_nonboot_cpus() > _cpu_down() > cpu_hotplug_begin() > mutex_lock(&cpu_hotplug.lock); > __cpu_notify() > padata_cpu_callback() > __padata_remove_cpu() > padata_replace() > synchronize_rcu() > rcu_gp_kthread() > get_online_cpus(); > mutex_lock(&cpu_hotplug.lock); It would of course be good to eliminate grace-period delays from CPU-hotplug notifiers, but that is a separate issue. Deadlock is not an appropriate diagnostic for excessive CPU-hotplug latency. Fortunately, grace-period initialization does not actually need to exclude all of the CPU-hotplug operation, but rather only RCU's own CPU_UP_PREPARE and CPU_DEAD CPU-hotplug notifiers. This commit therefore introduces a new per-rcu_state onoff_mutex that provides the required concurrency control in place of the get_online_cpus() that was previously in rcu_gp_init(). Reported-by: "Kirill A. Shutemov" <kirill@shutemov.name> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Diffstat (limited to 'init')
0 files changed, 0 insertions, 0 deletions