Re: [PATCH] signal: Use list_del_init_careful() in flush_sigqueue()

[Oleg Nesterov]

On 08/25, Thomas Gleixner wrote:
>
> On Mon, Aug 24 2026 at 15:59, Frederic Weisbecker wrote:
> > Le Mon, Aug 24, 2026 at 01:54:26PM +0200, Oleg Nesterov a écrit :
> >> > Hmm, at first glance... If we change de_thread() to do this _after_ transfer_pid's
> >> > (before release_task(leader)), then posixtimer_send_sigqueue() doesn't need any
> >> > changes, no?
> >>
> >> IOW. Unless I am totally confused, we only need to flush the
> >> SIGQUEUE_PREALLOC sigqueue's which were sent to the (old) leader
> >> before it changed its pid. So we can do this
> >>
> >> diff --git a/fs/exec.c b/fs/exec.c
> >> index a14f28b15607..550367e7fe6c 100644
> >> --- a/fs/exec.c
> >> +++ b/fs/exec.c
> >> @@ -1029,6 +1029,9 @@ static int de_thread(struct task_struct *tsk)
> >>  		write_unlock_irq(&tasklist_lock);
> >>  		cgroup_threadgroup_change_end(tsk);
> >>
> >> +		scoped_guard(spinlock_irq, lock)
> >> +			flush_sigqueue(&leader->pending);
> >> +
> >
> > Is there something to prevent the timer from firing on another CPU,
> > racing with this tiny window and queue the signal to the old leader? After
> > all exchange_tids() is just some RCU pointers changed but there is nothing
> > to synchronize the readers before the flush_sigqueue(). So pid_task() may
> > still return the old leader after it?
>
> You beat me to it.
>
> That's what I initialy thought when I added that exiting check into
> posixtimer_send_queue(), but then the trivial variant lured me away. :)

I'm afraid I am wrong again... but if change posixtimer_send_sigqueue()
to check !PF_EXITING, de_thread() still can do flush_sigqueue() after
exchange_tids() outside of tasklist_lock?

And I'd suggest to check t->exit_state instead of PF_EXITING,
posixtimer_send_sigqueue() can't miss it if it is called after
scoped_guard(spinlock_irq, lock).

Oleg.