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: <CAJZ5v0hURC-mhHszh=BhrGYfP9hwCs_nTQVxmtnV4Ot2yuajLA@mail.gmail.com>
Date:   Tue, 12 Jul 2022 20:53:59 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     xiongxin <xiongxin@...inos.cn>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        Riwen Lu <luriwen@...inos.cn>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next 2/2] PM: suspend: advanced pm_wakeup_clear() for
 normal suspend/hibernate

On Wed, Jun 29, 2022 at 5:35 AM xiongxin <xiongxin@...inos.cn> wrote:
>
> pm_wakeup_clear() will clear the wakeup source, which can ensure that it
> is not disturbed by useless wakeup signals when doing suspend/hibernate;
>
> At the beginning of the suspend/hibernate process, the notifier
> mechanism is used to notify other device drivers. This action is
> time-consuming (second-level time-consuming). If the process fails due
> to the received wakeup signal during the execution of these functions,
> it can better improve the experience of failing suspend/hibernate
> returns;
>
> Therefore, it is recommended here that for the suspend/hibernate process
> normally called from /sys/power/state, the pm_wakeup_clear() function
> should be brought before the notifier call; for the freeze_process()
> function called from other places, the original logic is kept;
>
> The pm_suspend_target_state variable is used here to identify whether the
> suspend process is going normally.

You seem to be arguing that the previous wakeup IRQ should be cleared
before invoking PM notifiers.  However, it is only set in
pm_system_irq_wakeup() which is only called after
suspend_device_irqs(), so clearing it anywhere before calling that
function in the given cycle should be sufficient.

> Signed-off-by: xiongxin <xiongxin@...inos.cn>
> ---
>  kernel/power/process.c | 5 ++++-
>  kernel/power/suspend.c | 6 ++++++
>  2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index 3068601e585a..3fde0240b3d1 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -131,7 +131,10 @@ int freeze_processes(void)
>         if (!pm_freezing)
>                 atomic_inc(&system_freezing_cnt);
>
> -       pm_wakeup_clear(0);
> +       if (pm_suspend_target_state != PM_SUSPEND_ON)
> +               pm_wakeup_clear(1);

This doesn't make sense.

> +       else
> +               pm_wakeup_clear(0);
>         pr_info("Freezing user space processes ... ");
>         pm_freezing = true;
>         error = try_to_freeze_tasks(true);
> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
> index c754b084ec03..f4259f6c1cc2 100644
> --- a/kernel/power/suspend.c
> +++ b/kernel/power/suspend.c
> @@ -569,6 +569,12 @@ static int enter_state(suspend_state_t state)
>          * performed from the /sys/power/state entry.
>          */
>         pm_suspend_target_state = state;
> +       /*
> +        * Put pm_wakeup_clear() before the notifier notification chain to
> +        * optimize in the suspend process, the wakeup signal can interrupt
> +        * the suspend in advance and fail to return.
> +        */

The comment above is too hard to understand for me, sorry.

> +       pm_wakeup_clear(0);
>
>         if (sync_on_suspend_enabled) {
>                 trace_suspend_resume(TPS("sync_filesystems"), 0, true);
> --
> 2.25.1
>
>
> No virus found
>                 Checked by Hillstone Network AntiVirus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ