| Message ID | 20140205221052.19080.77507.stgit@srivatsabhat.in.ibm.com (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Thursday, February 06, 2014 03:40:53 AM Srivatsa S. Bhat wrote: > Subsystems that want to register CPU hotplug callbacks, as well as perform > initialization for the CPUs that are already online, often do it as shown > below: > > get_online_cpus(); > > for_each_online_cpu(cpu) > init_cpu(cpu); > > register_cpu_notifier(&foobar_cpu_notifier); > > put_online_cpus(); > > This is wrong, since it is prone to ABBA deadlocks involving the > cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently > with CPU hotplug operations). > > Instead, the correct and race-free way of performing the callback > registration is: > > cpu_maps_update_begin(); > > for_each_online_cpu(cpu) > init_cpu(cpu); > > /* Note the use of the double underscored version of the API */ > __register_cpu_notifier(&foobar_cpu_notifier); > > cpu_maps_update_done(); > > > Fix the acpi-cpufreq code by using this latter form of callback registration. > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: cpufreq@vger.kernel.org > Cc: linux-pm@vger.kernel.org > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Looks OK to me. How does it depend on the rest of your series? > --- > > drivers/cpufreq/acpi-cpufreq.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c > index 18448a7..e2eb471 100644 > --- a/drivers/cpufreq/acpi-cpufreq.c > +++ b/drivers/cpufreq/acpi-cpufreq.c > @@ -907,15 +907,16 @@ static void __init acpi_cpufreq_boost_init(void) > > acpi_cpufreq_driver.boost_supported = true; > acpi_cpufreq_driver.boost_enabled = boost_state(0); > - get_online_cpus(); > + > + cpu_maps_update_begin(); > > /* Force all MSRs to the same value */ > boost_set_msrs(acpi_cpufreq_driver.boost_enabled, > cpu_online_mask); > > - register_cpu_notifier(&boost_nb); > + __register_cpu_notifier(&boost_nb); > > - put_online_cpus(); > + cpu_maps_update_done(); > } > } > > > -- > To unsubscribe from this list: send the line "unsubscribe cpufreq" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/06/2014 06:13 PM, Rafael J. Wysocki wrote: > On Thursday, February 06, 2014 03:40:53 AM Srivatsa S. Bhat wrote: >> Subsystems that want to register CPU hotplug callbacks, as well as perform >> initialization for the CPUs that are already online, often do it as shown >> below: >> >> get_online_cpus(); >> >> for_each_online_cpu(cpu) >> init_cpu(cpu); >> >> register_cpu_notifier(&foobar_cpu_notifier); >> >> put_online_cpus(); >> >> This is wrong, since it is prone to ABBA deadlocks involving the >> cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently >> with CPU hotplug operations). >> >> Instead, the correct and race-free way of performing the callback >> registration is: >> >> cpu_maps_update_begin(); >> >> for_each_online_cpu(cpu) >> init_cpu(cpu); >> >> /* Note the use of the double underscored version of the API */ >> __register_cpu_notifier(&foobar_cpu_notifier); >> >> cpu_maps_update_done(); >> >> >> Fix the acpi-cpufreq code by using this latter form of callback registration. >> >> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> >> Cc: Viresh Kumar <viresh.kumar@linaro.org> >> Cc: cpufreq@vger.kernel.org >> Cc: linux-pm@vger.kernel.org >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > > Looks OK to me. How does it depend on the rest of your series? > Thank you! Same here, every patch depends only on the first patch in the series. (Except the raid5 and the xen/balloon patches which don't have any dependency). But I'll be posting a v2 of this patchset soon with a rename of the API.. Regards, Srivatsa S. Bhat >> --- >> >> drivers/cpufreq/acpi-cpufreq.c | 7 ++++--- >> 1 file changed, 4 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c >> index 18448a7..e2eb471 100644 >> --- a/drivers/cpufreq/acpi-cpufreq.c >> +++ b/drivers/cpufreq/acpi-cpufreq.c >> @@ -907,15 +907,16 @@ static void __init acpi_cpufreq_boost_init(void) >> >> acpi_cpufreq_driver.boost_supported = true; >> acpi_cpufreq_driver.boost_enabled = boost_state(0); >> - get_online_cpus(); >> + >> + cpu_maps_update_begin(); >> >> /* Force all MSRs to the same value */ >> boost_set_msrs(acpi_cpufreq_driver.boost_enabled, >> cpu_online_mask); >> >> - register_cpu_notifier(&boost_nb); >> + __register_cpu_notifier(&boost_nb); >> >> - put_online_cpus(); >> + cpu_maps_update_done(); >> } >> } >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe cpufreq" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 6 February 2014 03:40, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > Subsystems that want to register CPU hotplug callbacks, as well as perform > initialization for the CPUs that are already online, often do it as shown > below: > > get_online_cpus(); > > for_each_online_cpu(cpu) > init_cpu(cpu); > > register_cpu_notifier(&foobar_cpu_notifier); > > put_online_cpus(); > > This is wrong, since it is prone to ABBA deadlocks involving the > cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently > with CPU hotplug operations). > > Instead, the correct and race-free way of performing the callback > registration is: > > cpu_maps_update_begin(); > > for_each_online_cpu(cpu) > init_cpu(cpu); > > /* Note the use of the double underscored version of the API */ > __register_cpu_notifier(&foobar_cpu_notifier); > > cpu_maps_update_done(); > > > Fix the acpi-cpufreq code by using this latter form of callback registration. > > Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> > Cc: Viresh Kumar <viresh.kumar@linaro.org> > Cc: cpufreq@vger.kernel.org > Cc: linux-pm@vger.kernel.org > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c index 18448a7..e2eb471 100644 --- a/drivers/cpufreq/acpi-cpufreq.c +++ b/drivers/cpufreq/acpi-cpufreq.c @@ -907,15 +907,16 @@ static void __init acpi_cpufreq_boost_init(void) acpi_cpufreq_driver.boost_supported = true; acpi_cpufreq_driver.boost_enabled = boost_state(0); - get_online_cpus(); + + cpu_maps_update_begin(); /* Force all MSRs to the same value */ boost_set_msrs(acpi_cpufreq_driver.boost_enabled, cpu_online_mask); - register_cpu_notifier(&boost_nb); + __register_cpu_notifier(&boost_nb); - put_online_cpus(); + cpu_maps_update_done(); } }
Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(&foobar_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Instead, the correct and race-free way of performing the callback registration is: cpu_maps_update_begin(); for_each_online_cpu(cpu) init_cpu(cpu); /* Note the use of the double underscored version of the API */ __register_cpu_notifier(&foobar_cpu_notifier); cpu_maps_update_done(); Fix the acpi-cpufreq code by using this latter form of callback registration. Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> --- drivers/cpufreq/acpi-cpufreq.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html