On 10/10/2011 06:03 PM, Srivatsa S. Bhat wrote: > Don't allow cpu hotplug online operation and suspend/hibernate to run in > parallel. If suspend/hibernate has already started, fail the cpu online > operation. > > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> > --- > > kernel/cpu.c | 10 ++++++++++ > 1 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/kernel/cpu.c b/kernel/cpu.c > index 12b7458..bc8c7d4 100644 > --- a/kernel/cpu.c > +++ b/kernel/cpu.c > @@ -15,6 +15,7 @@ > #include <linux/stop_machine.h> > #include <linux/mutex.h> > #include <linux/gfp.h> > +#include <linux/suspend.h> > > #ifdef CONFIG_SMP > /* Serializes the updates to cpu_online_mask, cpu_present_mask */ > @@ -366,6 +367,14 @@ int __cpuinit cpu_up(unsigned int cpu) > } > #endif > > + /* > + * Prevent cpu online and suspend/hibernate (including freezer) > + * operations from running in parallel. Fail cpu online if suspend or > + * hibernate has already started. > + */ > + if (!trylock_pm_sleep()) Would it be better to hook into the suspend/hibernate notifiers and use them to exclude cpu hotplug from suspend/hibernate, instead of trying to take pm_mutex lock like this? Peter, I remember you pointing out in another patch's review (http://thread.gmane.org/gmane.linux.kernel/1198312/focus=1199087) that introducing more locks in cpu hotplug would be a bad idea. Does that comment hold here as well, or is this fine? Anyways, I'll start working on that other implementation that hooks onto the suspend/hibernate notifiers and see if that works out better. > + return -EBUSY; > + > cpu_maps_update_begin(); > > if (cpu_hotplug_disabled) { > @@ -377,6 +386,7 @@ int __cpuinit cpu_up(unsigned int cpu) > > out: > cpu_maps_update_done(); > + unlock_pm_sleep(); > return err; > } > > -- Regards, Srivatsa S. Bhat <srivatsa.bhat@xxxxxxxxxxxxxxxxxx> Linux Technology Center, IBM India Systems and Technology Lab -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
