From: David Laight <david.laight.linux@gmail.com>
To: Hauke Mehrtens <hauke@hauke-m.de>
Cc: sashal@kernel.org, linux-kernel@vger.kernel.org,
frederic@kernel.org, david@redhat.com, viro@zeniv.linux.org.uk,
paulmck@kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] kernel/fork: Increase minimum number of allowed threads
Date: Wed, 16 Jul 2025 12:46:07 +0100 [thread overview]
Message-ID: <20250716124607.50fc5e34@pumpkin> (raw)
In-Reply-To: <0e855c4f-2ff9-4007-854a-20955dec052b@hauke-m.de>
On Sat, 12 Jul 2025 01:06:07 +0200
Hauke Mehrtens <hauke@hauke-m.de> wrote:
> On 7/12/25 01:03, Hauke Mehrtens wrote:
> > From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Sorry this has the wrong from tag, will send a new patch.
>
> Hauke>
> > 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 calles 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 bet it doesn't - it is likely to fail somewhere else instead.
While 20 is probably too low, the real issue seems to be that
the hotplug notifications need rate limiting.
David
> >
> > I saw the problem with qemu 10.0.2 using these commands:
> > qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Hauke Mehrtens <hauke@hauke-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
> >
> > /*
> > * Maximum number of threads
>
>
prev parent reply other threads:[~2025-07-16 11:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-11 23:03 [PATCH] kernel/fork: Increase minimum number of allowed threads Hauke Mehrtens
2025-07-11 23:06 ` Hauke Mehrtens
2025-07-16 11:46 ` David Laight [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250716124607.50fc5e34@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=david@redhat.com \
--cc=frederic@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hauke@hauke-m.de \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.