linux-kernel - Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support

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]

Message-ID: <CAJZ5v0j3a_m5T9nbxk4VSuABOq12JEC0fi=0SQ8+=Vwv-qDeOA@mail.gmail.com>
Date:   Thu, 21 Oct 2021 21:02:24 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Maulik Shah <mkshah@...eaurora.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Len Brown <len.brown@...el.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] PM: sleep: Fix runtime PM based cpuidle support

On Thu, Oct 21, 2021 at 8:12 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Thu, 21 Oct 2021 at 18:33, Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Thu, Oct 21, 2021 at 6:17 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:

[cut]

> > So in theory you could check the pm_runtime_put_sync_suspend() return
> > value and fall back to something like WFI if that's an error code.
>
> I have already tried that, but it simply got too complicated. The main
> issue was that runtime PM could become disabled for the device in the
> middle of executing the ->enter() callback.

So IIUC the problem is that you cannot resume after suspending in that case.

IOW, you need to guarantee that if the suspend is successful, the
resume also will take place, but if the suspend fails, you basically
don't care.

> For example, if pm_runtime_get_sync() fails, I still need to make sure
> the reference counting in genpd becomes correct - and I can't do that
> using dev_pm_genpd_resume(). That's because it's not designed to be
> called in this "unknown" suspend phase, but should be called after the
> noirq phase and be properly balanced with dev_pm_genpd_suspend().
>
> In other words, the error path didn't work out for me.

It should be sufficient to call wake_up_all_idle_cpus() in the suspend
path before dpm_suspend_late(), because system suspend acquires a
PM-runtime reference on every device.  IOW, it won't let any devices
runtime-suspend, so if your power domain devices are resumed in that
path, they will never suspend again in it and the
pm_runtime_put_sync_suspend() in __psci_enter_domain_idle_state()
becomes a reference counter management call which works regardless of
whether or not PM runtime is disabled.