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] [day] [month] [year] [list]

Message-ID: <83513599-e007-4d07-ac28-386bc5c7552d@kylinos.cn>
Date: Mon, 9 Jun 2025 12:05:14 +0800
From: zhangzihuan <zhangzihuan@...inos.cn>
To: Peter Zijlstra <peterz@...radead.org>
Cc: rafael@...nel.org, len.brown@...el.com, pavel@...nel.org,
 kees@...nel.org, mingo@...hat.com, 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, david@...hat.com, 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

Hi Peter,
Thanks a lot for the feedback!

在 2025/6/6 16:22, Peter Zijlstra 写道:
> This isn't blocking fork(), this is failing fork(). Huge difference.
> Also problematic, because -EBUSY is not a recognised return value of
> fork(). As such, no existing software will adequately handle it.
>  I completely agree there's a significant difference between failing 
> and blocking fork().
The intent was to prevent late-created user tasks from interfering with 
the freezing process, but you're right: returning -EBUSY is not valid 
for fork(), and existing user-space programs wouldn't expect or handle 
that properly.
As a next step, I'm considering switching to a blocking mechanism 
instead — that is, have user fork() temporarily sleep if it's attempted 
during the freeze window. That should avoid breaking user-space 
expectations while still helping maintain freeze stability.
Would that be more acceptable?
Thanks again for the insight,
Zihuan Zhang