[PATCH v2] PM: sleep: Use complete() in device_pm_sleep_init() and skip no_pm devices in dpm_wait()

Jiakai Xu posted 1 patch 1 month ago
There is a newer version of this series
drivers/base/power/main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
[PATCH v2] PM: sleep: Use complete() in device_pm_sleep_init() and skip no_pm devices in dpm_wait()
Posted by Jiakai Xu 1 month ago
Replace complete_all() with complete() in device_pm_sleep_init() to avoid
a false-positive WARNING from lockdep_assert_RT_in_threaded_ctx() when
CONFIG_PROVE_RAW_LOCK_NESTING is enabled. The WARNING triggers because
complete_all() may be called in atomic context (e.g., from
device_pm_remove() during network namespace cleanup which holds a
raw_spinlock).

complete_all() sets the completion count to UINT_MAX/2 (permanently
signaled), while complete() sets it to 1. Since no threads can be waiting
during device initialization, both are equivalent at that point. The
completion is always reinitialized via reinit_completion() in
dpm_clear_async_state() before each suspend/resume phase.

However, changing to complete() introduces a potential deadlock for
devices with no PM support (dev->power.no_pm = true). Such devices are
never added to the dpm_list and do not go through dpm_clear_async_state(),
so their completion is never reinitialized. A parent device waiting on a
no_pm child across multiple suspend phases would consume the single-use
token in the first phase and block forever in the second.

Fix this by adding an early return in dpm_wait() when dev->power.no_pm is
set, since no_pm devices do not participate in system suspend/resume.

Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend")
Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
---
V1 -> V2:
- Updated dpm_wait() to skip devices with no PM support,
  as suggested by Rafael J. Wysocki.
---
 drivers/base/power/main.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e1b550664bab..ed48c292f575 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -115,7 +115,7 @@ void device_pm_sleep_init(struct device *dev)
 	dev->power.is_noirq_suspended = false;
 	dev->power.is_late_suspended = false;
 	init_completion(&dev->power.completion);
-	complete_all(&dev->power.completion);
+	complete(&dev->power.completion);
 	dev->power.wakeup = NULL;
 	INIT_LIST_HEAD(&dev->power.entry);
 }
@@ -252,6 +252,10 @@ static void dpm_wait(struct device *dev, bool async)
 	if (!dev)
 		return;
 
+	/* Devices with no PM support don't use the completion. */
+	if (dev->power.no_pm)
+		return;
+
 	if (async || (pm_async_enabled && dev->power.async_suspend))
 		wait_for_completion(&dev->power.completion);
 }
-- 
2.34.1
Re: [PATCH v2] PM: sleep: Use complete() in device_pm_sleep_init() and skip no_pm devices in dpm_wait()
Posted by Rafael J. Wysocki 3 weeks ago
On Wed, May 13, 2026 at 4:15 AM Jiakai Xu <xujiakai24@mails.ucas.ac.cn> wrote:
>
> Replace complete_all() with complete() in device_pm_sleep_init() to avoid
> a false-positive WARNING from lockdep_assert_RT_in_threaded_ctx() when
> CONFIG_PROVE_RAW_LOCK_NESTING is enabled. The WARNING triggers because
> complete_all() may be called in atomic context (e.g., from
> device_pm_remove() during network namespace cleanup which holds a
> raw_spinlock).
>
> complete_all() sets the completion count to UINT_MAX/2 (permanently
> signaled), while complete() sets it to 1. Since no threads can be waiting
> during device initialization, both are equivalent at that point. The
> completion is always reinitialized via reinit_completion() in
> dpm_clear_async_state() before each suspend/resume phase.
>
> However, changing to complete() introduces a potential deadlock for
> devices with no PM support (dev->power.no_pm = true). Such devices are
> never added to the dpm_list and do not go through dpm_clear_async_state(),
> so their completion is never reinitialized. A parent device waiting on a
> no_pm child across multiple suspend phases would consume the single-use
> token in the first phase and block forever in the second.
>
> Fix this by adding an early return in dpm_wait() when dev->power.no_pm is
> set, since no_pm devices do not participate in system suspend/resume.
>
> Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend")
> Signed-off-by: Jiakai Xu <xujiakai24@mails.ucas.ac.cn>
> ---
> V1 -> V2:
> - Updated dpm_wait() to skip devices with no PM support,
>   as suggested by Rafael J. Wysocki.

Please see the sashiko.dev feedback on this:

https://sashiko.dev/#/patchset/20260513021509.483108-1-xujiakai24%40mails.ucas.ac.cn

AFAICS, it has a point in the first comment (not so much in the second one).

> ---
>  drivers/base/power/main.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index e1b550664bab..ed48c292f575 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -115,7 +115,7 @@ void device_pm_sleep_init(struct device *dev)
>         dev->power.is_noirq_suspended = false;
>         dev->power.is_late_suspended = false;
>         init_completion(&dev->power.completion);
> -       complete_all(&dev->power.completion);
> +       complete(&dev->power.completion);
>         dev->power.wakeup = NULL;
>         INIT_LIST_HEAD(&dev->power.entry);
>  }
> @@ -252,6 +252,10 @@ static void dpm_wait(struct device *dev, bool async)
>         if (!dev)
>                 return;
>
> +       /* Devices with no PM support don't use the completion. */
> +       if (dev->power.no_pm)
> +               return;
> +
>         if (async || (pm_async_enabled && dev->power.async_suspend))
>                 wait_for_completion(&dev->power.completion);
>  }
> --
> 2.34.1
>
Re: [PATCH v2] PM: sleep: Use complete() in device_pm_sleep_init() and skip no_pm devices in dpm_wait()
Posted by Jiakai Xu 2 weeks, 6 days ago
> Please see the sashiko.dev feedback on this:
> 
> https://sashiko.dev/#/patchset/20260513021509.483108-1-xujiakai24%40mails.ucas.ac.cn
> 
> AFAICS, it has a point in the first comment (not so much in the second one).

Thank you for the review and for pointing out the sashiko.dev feedback.

I will send a v3 with the corrected commit message shortly.

Best regards,
Jiakai