[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1604290240560.3718@nanos>
Date: Fri, 29 Apr 2016 02:44:40 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Lianwei Wang <lianwei.wang@...il.com>
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 Thu, 28 Apr 2016, Lianwei Wang wrote:
> 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.
Wrong. This is the symptom. The root cause is in #1. Therefor you are trying
to fix the symptom and not the root cause
> Anything not clear?
No.
I completely understand that you are tyring to put the cart before the horse.
Thanks,
tglx
Powered by blists - more mailing lists