From: Oleg Nesterov <oleg@redhat.com>
To: Matt Fleming <mfleming@cloudflare.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
John Stultz <jstultz@google.com>,
kernel-team <kernel-team@cloudflare.com>,
LKML <linux-kernel@vger.kernel.org>,
Chris Arges <carges@cloudflare.com>
Subject: Re: Debugging lost task in wait_task_inactive() when delivering signal (6.12)
Date: Fri, 19 Sep 2025 16:37:26 +0200 [thread overview]
Message-ID: <20250919143611.GA22933@redhat.com> (raw)
In-Reply-To: <CAGis_TWyhciem6bPzR98ysj1+gOVPHRGqSUNiiyvS1RnEidExw@mail.gmail.com>
Hi Matt,
On 09/19, Matt Fleming wrote:
>
> Hi there,
>
> We're running into an intermittent issue where tasks end up in a state with
> p->on_rq=1 and p->se.on_rq=0 when delivering a fatal signal to a thread
> group. The thread handling the signal sits in wait_task_inactive() after
> sending a SIGKILL to all other threads, most of which pass through
> coredump_task_exit() just fine, but occasionally one thread calls into
> coredump_task_exit()->schedule() and never comes back because of the above
> state.
I guess you mean coredump_wait() -> wait_task_inactive() ... Sorry I have no
clue at least right now... And I don't see any problem in coredump_task_exit().
Stupid question. Any chance you can reproduce, figure out the pid of that
sub-thread which fools wait_task_inactive() and, say, do
"cat /proc/pid-of-that-thread/stack" ? Or any other info, everything can
help. Crash dump? Yes, you have already mentioned this is hard-to-reproduce :(
Oleg.
next parent reply other threads:[~2025-09-19 14:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAGis_TWyhciem6bPzR98ysj1+gOVPHRGqSUNiiyvS1RnEidExw@mail.gmail.com>
2025-09-19 14:37 ` Oleg Nesterov [this message]
2025-09-19 15:16 ` Debugging lost task in wait_task_inactive() when delivering signal (6.12) Matt Fleming
2025-09-19 16:13 ` Oleg Nesterov
2025-09-20 22:10 ` Matt Fleming
2025-09-21 19:27 ` Oleg Nesterov
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=20250919143611.GA22933@redhat.com \
--to=oleg@redhat.com \
--cc=carges@cloudflare.com \
--cc=jstultz@google.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mfleming@cloudflare.com \
--cc=peterz@infradead.org \
/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.