linux-kernel - Re: [RFC PATCH] PM: Optionally block user fork during freeze to improve performance

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: <5mj4mc7asiplmgbqyl2uaw5cdpt6dpdrhtapi63dcrowozcwuq@c4cxyaxwe6aw>
Date: Sun, 8 Jun 2025 17:50:33 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: zhangzihuan <zhangzihuan@...inos.cn>
Cc: David Hildenbrand <david@...hat.com>, rafael@...nel.org, 
	len.brown@...el.com, pavel@...nel.org, kees@...nel.org, mingo@...hat.com, 
	peterz@...radead.org, juri.lelli@...hat.com, vincent.guittot@...aro.org, 
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de, 
	vschneid@...hat.com, akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com, 
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org, surenb@...gle.com, 
	mhocko@...e.com, linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org
Subject: Re: [RFC PATCH] PM: Optionally block user fork during freeze to
 improve performance

On Sun, Jun 08, 2025 at 03:22:20PM +0800, zhangzihuan wrote:
> One alternative could be to block in kernel_clone() until freezing ends,
> instead of returning an error. That way, fork() would not fail, just
> potentially block briefly (similar to memory pressure or cgroup limits). Do
> you think that's more acceptable?

So I had a look at the freezing loop and it operates with
tasklist_lock held, meaning it already stalls clone().

try_to_freeze_tasks() in kernel/power/process.c contains:

	todo = 0;
	read_lock(&tasklist_lock);
	for_each_process_thread(g, p) {
		if (p == current || !freeze_task(p))
			continue;

		todo++;
	}
	read_unlock(&tasklist_lock);

I don't get where the assumption that fork itself is a factor is coming
from.

Looking at freezing itself it seems to me perf trouble starts with tons
of processes existing to begin with in arbitrary states (not with racing
against fork), requring a retry with preceeded by a sleep:

	/*
	 * We need to retry, but first give the freezing tasks some
	 * time to enter the refrigerator.  Start with an initial
	 * 1 ms sleep followed by exponential backoff until 8 ms.
	 */
	usleep_range(sleep_usecs / 2, sleep_usecs);
	if (sleep_usecs < 8 * USEC_PER_MSEC)
		sleep_usecs *= 2;

For a race against fork to have any effect, the new thread has to be
linked in to the global list -- otherwise the todo var wont get bumped.

But then if it gets added in a state which is freezable, the racing fork
did not cause any trouble.

If it gets added in a state which is *NOT* freezable by the current
code, maybe it should be patched to be freezable.

All in all I'm not confident any of this warrants any work -- do you
have a setup where the above causes a real problem?