Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes:
> On Wed, 24 Jun 2015, Vitaly Kuznetsov wrote:
>
>> Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:
>>
>> > On Tue, Jun 23, 2015 at 04:57:05PM +0000, KY Srinivasan wrote:
>> >
>> >> > diff --git a/kernel/cpu.c b/kernel/cpu.c
>> >> > index 94bbe46..8f35ee6 100644
>> >> > --- a/kernel/cpu.c
>> >> > +++ b/kernel/cpu.c
>> >> > @@ -190,17 +190,19 @@ void cpu_hotplug_done(void)
>> >> > void cpu_hotplug_disable(void)
>> >> > {
>> >> > cpu_maps_update_begin();
>> >> > - cpu_hotplug_disabled = 1;
>> >> > + cpu_hotplug_disabled++;
>> >> > cpu_maps_update_done();
>> >> > }
>> >> > +EXPORT_SYMBOL_GPL(cpu_hotplug_disable);
>> >> >
>> >> > void cpu_hotplug_enable(void)
>> >> > {
>> >> > cpu_maps_update_begin();
>> >> > - cpu_hotplug_disabled = 0;
>> >> > + if (cpu_hotplug_disabled)
>> >> > + cpu_hotplug_disabled--;
>> >
>> > No that just papers over bugs.
>> >
>>
>> Yes, but these bugs are not in Linux. I don't see any other way for a
>> platform to enable/disable cpu hotplug in runtime.
>
> What? cpu_hotplug_disable()/enable() do that today. They just do not
> support recursion and we have not yet seen any argument WHY that's
> required at all.
They do, my patch just exports them. Despite the fact that I have no
specific usecase in my mind at this time I still see a theoretical
possibility of this being useful - when two pieces of code are trying to
enable/disable cpu hotplug simultaneously. Without making
cpu_hotplug_disabled a counter disable->disable->enable sequence will
lead to cpu hotplug being enabled.
--
Vitaly
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
