linux-kernel - Re: [PATCH 2/2] PM: s2idle: Avoid holding the s2idle_lock when calling pm_wakeup

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: <CAJZ5v0hF_am9DsuwEUmmgpUp=1ZuAG8fdjYfQ5XxFmS_Y1pMog@mail.gmail.com>
Date: Thu, 6 Mar 2025 14:18:17 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org, 
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] PM: s2idle: Avoid holding the s2idle_lock when
 calling pm_wakeup_pending()

On Thu, Mar 6, 2025 at 12:36 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> There's no reason to hold the s2idle_lock longer than necessary. Let's
> instead acquire it when really needed in s2idle_enter().
>
> Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> ---
>  kernel/power/suspend.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index e7aca4e40561..ca09f26cbf4e 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -91,10 +91,10 @@ static void s2idle_enter(void)
>  {
>         trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, true);
>
> -       raw_spin_lock_irq(&s2idle_lock);

This is to prevent missing a wakeup event when pm_system_wakeup() runs
at this point on a different CPU.

If you move the locking, it may run as a whole between the
pm_wakeup_pending() check below and the s2idle_state update, so the
wakeup event will be missed.

With the locking in place, the pm_abort_suspend update in
pm_system_wakeup() may still happen at any time, but the code under
the lock in s2idle_wake() after it can only run before the lock is
acquired above or after it is released.

If s2idle_wake() in pm_system_wakeup() runs before the
raw_spin_lock_irq() above, the pm_wakeup_pending() check below will
notice the pm_abort_suspend set and return true, so the suspend will
be aborted (and the pm_abort_suspend update in pm_system_wakeup()
cannot be reordered entirely after the s2idle_wake() call because of
the locking there).

Now, if s2idle_wake() in pm_system_wakeup() runs after the
raw_spin_unlock_irq() below, it will notice the s2idle_state change
and it will update it to S2IDLE_STATE_WAKE, so the suspend will be
aborted.

I guess it would have helped if there had been a comment describing this ...

>         if (pm_wakeup_pending())
>                 goto out;
>
> +       raw_spin_lock_irq(&s2idle_lock);
>         s2idle_state = S2IDLE_STATE_ENTER;
>         raw_spin_unlock_irq(&s2idle_lock);
>
> @@ -111,11 +111,10 @@ static void s2idle_enter(void)
>         wake_up_all_idle_cpus();
>
>         raw_spin_lock_irq(&s2idle_lock);
> -
> - out:
>         s2idle_state = S2IDLE_STATE_NONE;
>         raw_spin_unlock_irq(&s2idle_lock);
>
> + out:
>         trace_suspend_resume(TPS("machine_suspend"), PM_SUSPEND_TO_IDLE, false);
>  }
>
> --