[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJFUiJgUDSYE+6MG3riVyFjhhqckeY_3nEqer52tkUOy_yBeOw@mail.gmail.com>
Date: Thu, 28 Apr 2016 10:25:12 -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 Wed, Apr 27, 2016 at 11:15 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Wed, 27 Apr 2016, Lianwei Wang wrote:
>> Yes. In our project, there is a kernel driver which register a pm
>> notifier. On some conditions this pm notifier will return an error and
>> abort the suspend process. The counter will be unbalanced in case it
>> happened.
>
> So what? You wreckaged your driver, so you fix it and be done with it.
Do you mean no pm_notifier callback can return an error or NOTIFY_BAD
to abort the suspend process?
It's not the driver issue. The driver return an error to abort the
suspend process on purpose. Why do you think it is not allowed to
return an error to abort suspend?
The issue is very clear as described below.
1. How the issue happened?
One of the pm notifier return error to abort suspend before
cpu_hotplug_disable() is called on PM_SUSPEND_PREPARE.
2. What's the result?
CPU hotplug work in a wrong way, or it doesn't work anymore. No way to
recover it.
3. The root cause is that there is no any handling for the unbalanced
cpu_hotplug_disable/enable calling. This patch add a protection for
such issue.
Anything not clear?
Powered by blists - more mailing lists