Thread (38 messages) 38 messages, 5 authors, 2025-08-15

Re: [RFC PATCH v1 5/9] freezer: set default freeze priority for PF_SUSPEND_TASK processes

From: Zihuan Zhang <hidden>
Date: 2025-08-11 09:54:36
Also in: linux-fsdevel, linux-mm, linux-pm, lkml

在 2025/8/11 17:46, Oleg Nesterov 写道:
On 08/11, Zihuan Zhang wrote:
quoted
在 2025/8/11 17:32, Oleg Nesterov 写道:
quoted
On 08/11, Zihuan Zhang wrote:
quoted
在 2025/8/8 22:39, Oleg Nesterov 写道:
quoted
On 08/07, Zihuan Zhang wrote:
quoted
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -147,6 +147,7 @@ int freeze_processes(void)

  	pm_wakeup_clear(0);
  	pm_freezing = true;
+	freeze_set_default_priority(current, FREEZE_PRIORITY_NEVER);
But why?

Again, freeze_task() will return false anyway, this process is
PF_SUSPEND_TASK.
I  think there is resaon put it here. For example, systemd-sleep is a
user-space process that executes the suspend flow.

  If we don’t set its freeze priority explicitly, our current code may end up
with this user process being the last one that cannot freeze.
How so? sorry I don't follow.
The problem is in this part:

+            if (user_only && !(p->flags & PF_KTHREAD) && round <
p->freeze_priority)
+                continue;

PF_SUSPEND_TASK is a user process, so it meets the “needs freezing”
condition and todo gets incremented.
             ^^^^^^^^^^^^^^^^^^^^^^^^^

No.
	if (p == current || !freeze_task(p))
		continue;

	todo++;

Again, again, freeze_task(p) returns false.
quoted
But it actually doesn’t need to freeze,
so resulting in an infinite loop
I don't think so.

Oleg.
Sorry, you’re right — it’s indeed unnecessary. In an earlier version, I 
incremented the counter before the continue, but I later removed that 
and forgot about it.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help