linux-kernel - Re: [PATCH v5 1/4] cpu_pm: add syscore

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:   Wed, 7 Feb 2018 14:01:56 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Marc Zyngier <marc.zyngier@....com>
Cc:     Derek Basehore <dbasehore@...omium.org>,
        linux-kernel@...r.kernel.org, Soby.Mathew@....com,
        sudeep.holla@....com, devicetree@...r.kernel.org,
        robh+dt@...nel.org, mark.rutland@....com, linux-pm@...r.kernel.org,
        rafael.j.wysocki@...el.com, tglx@...utronix.de
Subject: Re: [PATCH v5 1/4] cpu_pm: add syscore_suspend error handling

Hi Marc,

On Wed, Feb 07, 2018 at 08:57:27AM +0000, Marc Zyngier wrote:
> On 07/02/18 01:41, Derek Basehore wrote:
> > If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
> > will put the CPU in the correct state to resume from the failure.
> > 
> > Signed-off-by: Derek Basehore <dbasehore@...omium.org>
> > ---
> >  kernel/cpu_pm.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/kernel/cpu_pm.c b/kernel/cpu_pm.c
> > index 67b02e138a47..03bcc0751a51 100644
> > --- a/kernel/cpu_pm.c
> > +++ b/kernel/cpu_pm.c
> > @@ -186,6 +186,9 @@ static int cpu_pm_suspend(void)
> >  		return ret;
> >  
> >  	ret = cpu_cluster_pm_enter();
> > +	if (ret)
> > +		cpu_pm_exit();
> > +
> >  	return ret;
> >  }
> >  
> > 
> 
> It is unclear to me why we need this patch as part of the ITS series. I
> probably fixes something for you, but I don't see the connection with
> the other patches.

Ths bug was noticed (by inspection) along with earlier versions of this
series, when Derek was still adding new cpu_pm callbacks, and new
failure modes within the existing callbacks. It's a proper fix to my
knowledge, but I believe it no longer has any particular relevance to
this series, since we're not really touching cpu_pm in this series any
more.

Brian