FAILED: patch "[PATCH] fork: don't create io threads once PF_POSTCOREDUMP is set" failed to apply to 6.12-stable tree
Subsystems (4)
[email protected]
maintainerThe patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 1f978881ce6c9ac4f4d4a7b6a6e52339eadcd350
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026102850-unleveled-version-e04b@gregkh' --subject-prefix 'PATCH 6.12.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1f978881ce6c9ac4f4d4a7b6a6e52339eadcd350 Mon Sep 17 00:00:00 2001
From: Christian Brauner <[email protected]>
Date: Mon, 21 Sep 2026 15:45:03 +0200
Subject: [PATCH] fork: don't create io threads once PF_POSTCOREDUMP is set
zap_process() skips every thread that already has PF_POSTCOREDUMP set. Such a thread is past synchronize_group_exit(), so a coredump can't catch it anymore. It isn't counted in core_state->threads_remaining and it isn't sent SIGKILL.
do_exit() sets PF_POSTCOREDUMP in synchronize_group_exit() and calls io_uring_files_cancel() right after that. The cancellation runs task work and a create_worker_cb() that io-wq queued before the exit creates a new io-wq worker from there. If another thread started a coredump in the meantime that worker joins a thread-group which is already being dumped. zap_process() never saw it so it was never counted. But when it exits it sees signal->core_state in synchronize_group_exit() and decrements threads_remaining like any other thread.
So the count reaches zero one thread early and the dumper leaves coredump_wait_inactive() while a thread it counted is still running.
The task has no fatal signal pending because zap_process() deliberately didn't send it one, and it never went through get_signal() so it doesn't have PF_SIGNALED either.
Refuse to create an io thread when the creator has PF_POSTCOREDUMP. That costs nothing. io_uring_files_cancel() raises IO_WQ_BIT_EXIT before it runs any task work, so a worker created from there only ever gets to exit again, and io_should_retry_thread() doesn't retry -EINTR.
Clearing PF_POSTCOREDUMP for the new thread in copy_process() was the other option. It makes the worker a thread like any other, but it only helps while the dump hasn't started. A worker born after zap_process() has run is invisible to it whatever its flags say and still decrements threads_remaining on the way out. Refusing to create it covers both, and then no task is ever born with the flag, so there is nothing to clear.
Moving io_uring_files_cancel() ahead of synchronize_group_exit() closes the same window. It runs the cancellation, and whatever that can block on, before the thread announces itself to the dumper. A thread that blocks there never reaches coredump_task_exit() at all, so the dumper ends up waiting for a thread that never parks. Refusing the creation leaves the cancellation where it is. But it's very ugly to run io_uring work even before we did all the generic exit work.
kernel/fork.c +2 -2
@@ -2700,8 +2700,8 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node) .user_worker = 1, }; -/* A creator past its fatal signal gets no thread. */ -if (current->flags &PF_SIGNALED ) +/* A creator past its fatal signal or its coredump point gets no thread. */ +if (current->flags & (PF_SIGNALED |PF_POSTCOREDUMP ))return ERR_PTR (-EINTR );return copy_process (NULL ,0 , node, &args);
Sasha Levin
maintainerPATCH 1/2 fork: move the coredump and exec checks into create_io_thread()
From: Christian Brauner <[email protected]>
[ Upstream commit e760200370e4de054b6b5f568a7faa911e2956bb ]
Only a PF_USER_WORKER thread returns from get_signal() after a fatal signal and can go on to create a thread. get_signal() sets PF_SIGNALED before it dumps core and before it lets a PF_USER_WORKER thread return. That flags sticks.
The exec'ing thread itself is never signaled. But it doesn't need the check anyway as we moved cancellation of io_uring requests before de_thread(). create_io_thread() is the only way a signaled thread creates another one. vhost_task_create() is reached from ioctls alone.
io_should_retry_thread() doesn't retry -EINTR, so io-wq callers give up the same way they did when copy_process() refused.
Stable-dep-of: 1f978881ce6c ("fork: don't create io threads once PF_POSTCOREDUMP is set")
--- kernel/fork.c | 4 ++++ 1 file changed, 4 insertions(+)
kernel/fork.c +4 -0
@@ -2774,6 +2774,10 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node) .user_worker = 1, }; +/* A creator past its fatal signal gets no thread. */ +if (current->flags &PF_SIGNALED ) +return ERR_PTR (-EINTR ); +return copy_process (NULL ,0 , node, &args); }
Signature · 1 line
2.53.0
Sasha Levin
maintainerPATCH 2/2 fork: don't create io threads once PF_POSTCOREDUMP is set
From: Christian Brauner <[email protected]>
[ Upstream commit 1f978881ce6c9ac4f4d4a7b6a6e52339eadcd350 ]
zap_process() skips every thread that already has PF_POSTCOREDUMP set. Such a thread is past synchronize_group_exit(), so a coredump can't catch it anymore. It isn't counted in core_state->threads_remaining and it isn't sent SIGKILL.
do_exit() sets PF_POSTCOREDUMP in synchronize_group_exit() and calls io_uring_files_cancel() right after that. The cancellation runs task work and a create_worker_cb() that io-wq queued before the exit creates a new io-wq worker from there. If another thread started a coredump in the meantime that worker joins a thread-group which is already being dumped. zap_process() never saw it so it was never counted. But when it exits it sees signal->core_state in synchronize_group_exit() and decrements threads_remaining like any other thread.
So the count reaches zero one thread early and the dumper leaves coredump_wait_inactive() while a thread it counted is still running.
The task has no fatal signal pending because zap_process() deliberately didn't send it one, and it never went through get_signal() so it doesn't have PF_SIGNALED either.
Refuse to create an io thread when the creator has PF_POSTCOREDUMP. That costs nothing. io_uring_files_cancel() raises IO_WQ_BIT_EXIT before it runs any task work, so a worker created from there only ever gets to exit again, and io_should_retry_thread() doesn't retry -EINTR.
Clearing PF_POSTCOREDUMP for the new thread in copy_process() was the other option. It makes the worker a thread like any other, but it only helps while the dump hasn't started. A worker born after zap_process() has run is invisible to it whatever its flags say and still decrements threads_remaining on the way out. Refusing to create it covers both, and then no task is ever born with the flag, so there is nothing to clear.
Moving io_uring_files_cancel() ahead of synchronize_group_exit() closes the same window. It runs the cancellation, and whatever that can block on, before the thread announces itself to the dumper. A thread that blocks there never reaches coredump_task_exit() at all, so the dumper ends up waiting for a thread that never parks. Refusing the creation leaves the cancellation where it is. But it's very ugly to run io_uring work even before we did all the generic exit work.
--- kernel/fork.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/fork.c +2 -2
@@ -2774,8 +2774,8 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node) .user_worker = 1, }; -/* A creator past its fatal signal gets no thread. */ -if (current->flags &PF_SIGNALED ) +/* A creator past its fatal signal or its coredump point gets no thread. */ +if (current->flags & (PF_SIGNALED |PF_POSTCOREDUMP ))return ERR_PTR (-EINTR );return copy_process (NULL ,0 , node, &args);
Signature · 1 line
2.53.0