linux-kernel - Re: [PATCH v2] kernel/fork: Increase minimum number of allowed threads

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: <20250721225641.2691-1-hdanton@sina.com>
Date: Tue, 22 Jul 2025 06:56:40 +0800
From: Hillf Danton <hdanton@...a.com>
To: Hauke Mehrtens <hauke@...ke-m.de>
Cc: David Laight <david.laight.linux@...il.com>,
	Jiri Slaby <jirislaby@...nel.org>,
	linux-kernel@...r.kernel.org,
	Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH v2] kernel/fork: Increase minimum number of allowed threads

On Sun, 20 Jul 2025 17:28:20 +0200 Hauke Mehrtens wrote:
> Hi,
> 
> I am not exactly sure how I should limit the number of parallel user 
> mode helper calls.
> The user mode helper is calling wait_for_initramfs() so it could be that 
> some calls are getting queued at the early bootup. This is probably the 
> problem I am hitting.
> 
> I do not want to block the device creation till the user mode helper 
> finished. This could also result in a deadlock and would probably slow 
> down bootup.
> 
> When I limit the number of user mode helper calls to 1 and let the 
> others wait in a system queue, I might block other unrelated tasks in 
> the system queue.
> 
Can you specify how system queue is blocked, after a look at the false
deadlock [1]?

[1] https://lore.kernel.org/lkml/20240927112516.1136-1-hdanton@sina.com/

> I would create an own queue and let the async user mode helper wait in 
> this queue to only execute one at a time. When one of them needs a long 
> time in user space it would block the others. This workqueue would also 
> be active all the time. After the bootup it would probably not do much 
> work any more.
> 
> I do not like any of these solutions. Do you have better ideas?