linux-kernel - Re: [PATCH] PM: sleep: call devfreq_suspend/resume and cpufreq

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] [day] [month] [year] [list]

Message-ID: <CAAfSe-uv7fh5Wf7zXLOu0_5wZ2fNQHd3QJ7LWWZvciexvUgivw@mail.gmail.com>
Date:   Thu, 23 Apr 2020 10:41:07 +0800
From:   Chunyan Zhang <zhang.lyra@...il.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Orson Zhai <orsonzhai@...il.com>,
        Vincent Wang <vincent.wang@...soc.com>,
        Samer Xie <samer.xie@...soc.com>,
        Chunyan Zhang <chunyan.zhang@...soc.com>
Subject: Re: [PATCH] PM: sleep: call devfreq_suspend/resume and
 cpufreq_suspend/resume in pairs.

On Wed, 22 Apr 2020 at 22:21, Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Wed, Apr 22, 2020 at 1:19 PM Chunyan Zhang <zhang.lyra@...il.com> wrote:
> >
> > Hi Rafael,
> >
> > (Behalf Of Vincent Wang)
> >
> > Thanks for your comments, please see my answers below.
> >
> > On Wed, 22 Apr 2020 at 17:05, Rafael J. Wysocki <rafael@...nel.org> wrote:
> > >
> > > On Wed, Apr 22, 2020 at 7:15 AM Chunyan Zhang <zhang.lyra@...il.com> wrote:
> > > >
> > > > From: Vincent Wang <vincent.wang@...soc.com>
> > > >
> > > > If dpm_prepare() fails in dpm_suspend_start(), dpm_suspend() can't be
> > > > called.
> > >
> > > That's correct.
> > >
> > > > And then, devfreq_suspend() and cpufreq_suspend() will not be
> > > > called in the suspend flow.
> > >
> > > Right.
> > >
> > > > But in the resiume flow, devfreq_resume() and cpufreq_resume() will
> > > > be called.
> > >
> > > Right, and they are expected to cope with the situation.
> > >
> > > > This patch will ensure that devfreq_suspend/devfreq_resume and
> > > > cpufreq_suspend/cpufreq_resume are called in pairs.
> > >
> > > So why is it better to do this than to make devfreq_resume() meet the
> > > expectations?
> >
> > Yes，we found an issue with cpufreq schedutil governor on kernel4.14,
> > and I think the issue should haven't been changed on the latest
> > version of kernel.
> >
> > In the function dpm_suspend_start(), dpm_suspend() would not be
> > exceuted if return error from device_prepare() [1]. So
> > cpufreq_cpufreq() will not be called,
>
> I guess you mean cpufreq_suspend().
>
> That should be OK .
>
> > then cpufreq_remove_update_util_hook() will not be called either, and so
> > cpufreq_update_util_data will not be NULL.
> >
> > In the dpm resume flow, sugov_start() will be called, in which
> > sg_cpu.update_util will be set to 0.
>
> Which code patch does this?
>
> Surely not cpufreq_resume(), because that checks cpufreq_suspended which
> cannot be set if cpufreq_suspend() has not been called (because it is the only
> place setting cpufreq_suspended).

Right, I saw that, then there's no issue indeed. I just need to
backport the patch which added checking of cpufreq_suspended to
cpufreq_resume.

Thanks for your review!