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

Message-ID: <576d1040-4238-4bf0-aa61-e1261a38d780@hauke-m.de>
Date: Fri, 18 Jul 2025 00:52:30 +0200
From: Hauke Mehrtens <hauke@...ke-m.de>
To: David Laight <david.laight.linux@...il.com>,
 Jiri Slaby <jirislaby@...nel.org>
Cc: sashal@...nel.org, linux-kernel@...r.kernel.org, frederic@...nel.org,
 david@...hat.com, viro@...iv.linux.org.uk, paulmck@...nel.org,
 stable@...r.kernel.org, Tejun Heo <tj@...nel.org>,
 Lai Jiangshan <jiangshanlai@...il.com>,
 "Luis R . Rodriguez" <mcgrof@...nel.org>
Subject: Re: [PATCH v2] kernel/fork: Increase minimum number of allowed
 threads

On 7/17/25 23:34, David Laight wrote:
> On Thu, 17 Jul 2025 07:26:59 +0200
> Jiri Slaby <jirislaby@...nel.org> wrote:
> 
>> Cc wqueue & umode helper folks
>>
>> On 12. 07. 25, 1:08, Hauke Mehrtens wrote:
>>> A modern Linux system creates much more than 20 threads at bootup.
>>> When I booted up OpenWrt in qemu the system sometimes failed to boot up
>>> when it wanted to create the 419th thread. The VM had 128MB RAM and the
>>> calculation in set_max_threads() calculated that max_threads should be
>>> set to 419. When the system booted up it tried to notify the user space
>>> about every device it created because CONFIG_UEVENT_HELPER was set and
>>> used. I counted 1299 calls to call_usermodehelper_setup(), all of
>>> them try to create a new thread and call the userspace hotplug script in
>>> it.
>>>
>>> This fixes bootup of Linux on systems with low memory.
>>>
>>> I saw the problem with qemu 10.0.2 using these commands:
>>> qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic
>>>
>>> Cc: stable@...r.kernel.org
>>> Signed-off-by: Hauke Mehrtens <hauke@...ke-m.de>
>>> ---
>>>    kernel/fork.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/fork.c b/kernel/fork.c
>>> index 7966c9a1c163..388299525f3c 100644
>>> --- a/kernel/fork.c
>>> +++ b/kernel/fork.c
>>> @@ -115,7 +115,7 @@
>>>    /*
>>>     * Minimum number of threads to boot the kernel
>>>     */
>>> -#define MIN_THREADS 20
>>> +#define MIN_THREADS 600
>>
>> As David noted, this is not the proper fix. It appears that usermode
>> helper should use limited thread pool. I.e. instead of
>> system_unbound_wq, alloc_workqueue("", WQ_UNBOUND, max_active) with
>> max_active set to max_threads divided by some arbitrary constant (3? 4?)?
> 
> Or maybe just 1 ?
> I'd guess all the threads either block in the same place or just block
> each other??

I will reduce the number of threads. Maybe to max 5 or maybe just one.

I think we should still increase the minimum number of threads, but 
something like 60 to 100 should be fine. It is calculated based RAM size 
128MB RAM resulted already in 419 max threads.

Hauke