From: Oleg Nesterov <oleg@redhat.com>
To: Hyunwoo Kim <imv4bel@gmail.com>
Cc: frederic@kernel.org, tglx@kernel.org, brauner@kernel.org,
peterz@infradead.org, anna-maria@linutronix.de,
ebiederm@xmission.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] signal: Use list_del_init_careful() in flush_sigqueue()
Date: Sun, 23 Aug 2026 14:47:10 +0200 [thread overview]
Message-ID: <aorrznOnJNqAxnh_@redhat.com> (raw)
In-Reply-To: <aok1rdkBgZsynHZB@v4bel>
On 08/22, Hyunwoo Kim wrote:
>
> commit fb3bbcfe344e ("exit: change the release_task() paths to call
> flush_sigqueue() lockless") moved the ->pending flush from __exit_signal()
> to release_task(), where it runs without ->siglock. The justification was:
>
> after the exiting task passes __exit_signal() lock_task_sighand() can't
> succeed and pid_task(tmr->it_pid) will return NULL
>
> That second half does not hold for the old group leader in a non-leader
> exec(). de_thread() calls exchange_tids() before release_task(leader), so
Indeed... Thanks a lot!
I need some time to (try to ;) fully understand the problem and your fix...
I'll read your patch again tomorrow with a clear head.
Now... I hope that the next paragraph
This means that after __exit_signal(tsk) nobody can play with tsk->pending
or (if group_dead) with tsk->signal->shared_pending,
from the changelog is still true, so the only problem is that it is not
safe to play with q->list, right?
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -482,7 +482,11 @@ void flush_sigqueue(struct sigpending *queue)
> sigemptyset(&queue->signal);
> while (!list_empty(&queue->list)) {
> q = list_entry(queue->list.next, struct sigqueue , list);
> - list_del_init(&q->list);
> + /*
> + * Pairs with the list_empty() in posixtimer_send_sigqueue().
> + * release_task() gets here without ->siglock.
> + */
> + list_del_init_careful(&q->list);
> __sigqueue_free(q);
Can't we avoid list_del_init() altogether? Can't flush_sigqueue() simply do
list_for_each_entry(q, &pending->list, list)
__sigqueue_free(q);
?
Oleg.
next prev parent reply other threads:[~2026-08-23 12:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 5:37 Hyunwoo Kim
2026-08-22 10:27 ` Bradley Morgan
2026-08-23 12:47 ` Oleg Nesterov [this message]
2026-08-24 2:53 ` Hyunwoo Kim
2026-08-24 8:28 ` Oleg Nesterov
2026-08-24 8:04 ` Thomas Gleixner
2026-08-24 9:45 ` Thomas Gleixner
2026-08-24 11:02 ` Oleg Nesterov
2026-08-24 11:54 ` Oleg Nesterov
2026-08-24 13:59 ` Frederic Weisbecker
2026-08-24 14:29 ` Oleg Nesterov
2026-08-24 12:11 ` Thomas Gleixner
2026-08-24 16:31 ` 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=aorrznOnJNqAxnh_@redhat.com \
--to=oleg@redhat.com \
--cc=anna-maria@linutronix.de \
--cc=brauner@kernel.org \
--cc=ebiederm@xmission.com \
--cc=frederic@kernel.org \
--cc=imv4bel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®