lkml.org 
[lkml]   [2016]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable
On Fri, Apr 22, 2016 at 9:37 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 22 Apr 2016, Lianwei Wang wrote:
>
>> On Thu, Apr 21, 2016 at 3:50 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>> > On Wed, Apr 20, 2016 at 09:56:07PM -0700, Lianwei Wang wrote:
>> >> Currently it just print a warning message but did not
>> >> reset cpu_hotplug_disabled when the enable/disable is
>> >> unbalanced. The unbalanced enable/disable will lead
>> >> the cpu hotplug work abnormally.
>> >>
>> >> Reset it to 0 when an unablanced enable detected.
>> >
>> > How can this happen in the first place?
>>
>> That's is my question too, and why we check it with WARN_ON here?
>> Obviously it is possible to happened because the
>> cpu_hotplug_disable/enable are both kernel API and any driver can call
>> it. A unbalanced check is a good way to handle it.
>>
>> The actually problem here is that what we do in case it happened? Just
>> give a warning or do some error handling and recover it back? This's
>> my focus..
>
> Actually we do nothing if it happens. We just emit a warning and that's good
> enough because the machine is still accessible and therefor debugable. It just
> renders cpu hotplug useless, but that's not a fundamental problem. If you look
> at the checks we do with preempt count, where we actually restore the counter
> that's a different issue. If we would not do that we simply would break the
> machine completely and end up in an endless storm of warnings. Different
> story, but that hotplug thing is just not in that class of problems.
>
> Thanks,
>
> tglx

Any way is Ok for debugging purpose. But think the kernel run on a
customer machine, such as PC, Mobile phone or other devices. How we
let the customer debug it but not recover it smartly?

If it happened then the cpu hotplug is not useless but may work in a
wrong way. E.g. the cpu_hotplug_disabled now is -1 after the last call
of cpu_hotplug_enable, then it is actually DISABLED but not enabled,
and the following call of cpu_hotplug_disable is actually enable but
not disable. There is no way for the customer or end user to recover
it except do a power cycle and reboot.

Anyway, from a product perspective way, if we don't want to restore
the unbalanced counter to 0, then maybe a BUG_ON is more reasonable
than WARN_ON.

\
 
 \ /
  Last update: 2016-04-23 00:21    [W:0.050 / U:0.728 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site