From: Oleg Nesterov <oleg@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Anthony Mallet <anthony.mallet@laas.fr>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
linux-kernel@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
Marco Elver <elver@google.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: posix timer freeze after some random time, under pthread create/destroy load
Date: Fri, 22 Nov 2024 12:49:50 +0100 [thread overview]
Message-ID: <20241122114949.GA24815@redhat.com> (raw)
In-Reply-To: <Z0BliWkMHHzohMt3@pavilion.home>
On 11/22, Frederic Weisbecker wrote:
>
> Le Fri, Nov 22, 2024 at 09:24:07AM +0100, Oleg Nesterov a écrit :
> > On 11/21, Frederic Weisbecker wrote:
> > >
> > > I think this started with commit:
> > >
> > > bcb7ee79029d (posix-timers: Prefer delivery of signals to the current thread)
> > >
> > > The problem is that if the current task is exiting and has already been reaped,
> > > its sighand pointer isn't there anymore.
> >
> > Thanks...
> >
> > This can only happen if the exiting task has already passed exit_notify() which
> > sets exit_state. So I'd suggest to check current->exit_state instead of PF_EXITING
> > in the patch below.
> >
> > Oleg.
>
> Right, I don't mind either way,
Me too, so feel free to ignore,
> though if it's past PF_EXITING,
> complete_signal() -> wants_signal() will defer to another thread anyway, right?
Right. So I think it would be better to rely on complete_signal() in this
case even if the current logic is very simple and dumb.
> Due to retarget_shared_pending() being called after the flag being set...
Yes. Whatever we do send_sigqueue/complete_signal can choose an exiting thread
which doesn't have PF_EXITING yet, in this case retarget_shared_pending() from
that thread will pick another target for signal_wake_up/TIF_SIGPENDING.
Thanks!
Oleg.
next prev parent reply other threads:[~2024-11-22 11:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 21:29 posix timer freeze after some random time, under pthread create/destroy load Anthony Mallet
2024-11-21 18:19 ` Frederic Weisbecker
2024-11-22 8:24 ` Oleg Nesterov
2024-11-22 11:05 ` Frederic Weisbecker
2024-11-22 11:49 ` Oleg Nesterov [this message]
2024-11-22 12:01 ` Frederic Weisbecker
2024-11-22 12:38 ` Oleg Nesterov
2024-11-22 12:58 ` Frederic Weisbecker
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=20241122114949.GA24815@redhat.com \
--to=oleg@redhat.com \
--cc=anna-maria@linutronix.de \
--cc=anthony.mallet@laas.fr \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.