linux-kernel - Re: [PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Apr 2016 23:58:51 -0700
From:	Lianwei Wang <lianwei.wang@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Peter Zijlstra <peterz@...radead.org>, oleg@...hat.com,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	linux-pm@...r.kernel.org
Subject: Re: [PATCH] cpu/hotplug: handle unbalanced hotplug enable/disable

On Mon, Apr 25, 2016 at 1:22 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Fri, 22 Apr 2016, Lianwei Wang wrote:
>> 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?
>
> There is nothing smart here. Restoring the count is a bandaid and has nothing
> to do with recovery. If that WARN_ON triggers then other stuff is going to be
> more fundamentally wrong so restoring the count is the least of our worries.
>
You are still think it from a developer view. You can not let the
customer/consumer to fix such issue, right? You even can not let the
customer/consumer to wait for the fix, right?

Take the suspend for example, the suspend_prepare will call
pm_notifier_call_chain to send PM_SUSPEND_PREPARE notification. If one
of the function on the chain return NOTIFY_BAD or NOTIFY_STOP before
calling cpu_hotplug_pm_callback, then either way will cause the
cpu_hotplug_disable() not called in
cpu_hotplug_pm_callback(PM_SUSPEND_PREPARE). When the suspend is going
to call pm_notifier_call_chain(PM_POST_SUSPEND) ->
cpu_hotplug_pm_callback -> cpu_hotplug_enable() , then it is
Unbalanced...

There are other paths to cause the counter unbalanced too. But no
matter how it is unbalanced, we can detect it and recover it to normal
state.

>> 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.
>
> Not at all. BUG_ON is the last resort if we have no other way to handle an
> issue.
Actually to the customer, you do nothing currently at all, and once it
happened then there is no way for the customer to recover it except do
a power cycle. A BUG_ON can trigger a power cycle and recover it.
>
> Thanks,
>
>         tglx