linux-kernel - Re: [PATCH v2 3/4] PM: suspend: Assign pm_suspend_target

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: <c1fd270f-624f-4a63-b54a-d2d98f06cb49@kylinos.cn>
Date: Thu, 3 Jul 2025 12:06:34 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: pavel@...nel.org, len.brown@...el.com, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 3/4] PM: suspend: Assign pm_suspend_target_state
 earlier for valid debug logs

Hi Rafael,

在 2025/7/3 02:58, Rafael J. Wysocki 写道:　 　 　 　　 　 　 　 　 　 　 　 

>> On Thu, Jun 19, 2025 at 5:54 AM Zihuan Zhang <zhangzihuan@...inos.cn> wrote:
>>
>> pm_suspend_target_state is used in debug logs inside enter_state(), but
>> it is only assigned inside suspend_devices_and_enter(), which is too late..
>>
>> This causes early pm_pr_dbg() output to either show incorrect state or
>> nothing at all, making suspend debugging harder.
>>
>> Assign pm_suspend_target_state at the beginning of enter_state() to ensure
>> early log output is meaningful.
>>
>> Signed-off-by: Zihuan Zhang
>>   ---
>> kernel/power/suspend.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
>> index 76b141b9aac0..16172ca22f21 100644
>> --- a/kernel/power/suspend.c
>> +++ b/kernel/power/suspend.c
>> @@ -584,6 +584,8 @@ static int enter_state(suspend_state_t state)
>> if (!mutex_trylock(&system_transition_mutex))
>> return -EBUSY;
>>
>> + pm_suspend_target_state = state;
>> +
>> if (state == PM_SUSPEND_TO_IDLE)
>> s2idle_begin();
>>
>> @@ -616,6 +618,7 @@ static int enter_state(suspend_state_t state)
>> suspend_finish();
>> Unlock:
>> filesystems_thaw();
>> + pm_suspend_target_state = PM_SUSPEND_ON;
>> mutex_unlock(&system_transition_mutex);
>> return error;
>> }}
>>
>> --
>> 　 　 　 　 　 　 　 　 　 　　 
> Good catch, but you should remove the existing assignments at the
> same time. 　
Thanks for your review and feedback.

You’re right that ideally pm_suspend_target_state should only be 
assigned once in enter_state(), and I initially considered removing the 
original assignment in suspend_devices_and_enter() as well.

However, I noticed that some drivers and subsystems may rely on the 
value of pm_suspend_target_state later in the suspend path, not just for 
logging but also for decision-making (e.g. conditional behavior based on 
suspend state). Because of this, I was cautious about removing the 
original assignment inside suspend_devices_and_enter() without verifying 
all potential dependencies.

Would you consider it acceptable to keep both assignments for now — one 
early for logging purposes, and one later to ensure correctness and 
compatibility — or do you think it’s preferable to remove the later one 
and carefully audit all usage sites?

Happy to adjust accordingly based on your recommendation.

Best regards,
Zihuan Zhang