Re: [PATCH] signal: Prevent exec() race

[Thomas Gleixner <tglx@kernel.org>]

On Mon, Aug 31 2026 at 14:52, Frederic Weisbecker wrote:
> Le Mon, Aug 31, 2026 at 12:50:46PM +0200, Thomas Gleixner a écrit :
>
> Is the following situation possible?
>
> CPU 0                                CPU 1                   CPU 2
> -----                                -----                   -----
>
> exit_signals()
>    spin_lock(sighand)
>    tsk->flags |= PF_EXITING;
>    spin_unlock(sighand)
>
>    flush_pending_unlocked(tsk);
>
>   ...
>   do_task_dead()
>                                      de_thread()
>                                         // acquired tsk->flags
>                                         // and signal flushed
>                                         // through tasklist_lock
>                                         transfer_pid()
>                                                            
>                                                            posix_timer_fn()
>                                                               posixtimer_send_sigqueue()
>                                                                  // happen to see new leader
>                                                                  t = posixtimer_get_target(tmr)
>                                                                  lock_task_sighand()
>                                                                  // passes !PF_EXITING cond
>                                                                  // but what makes sure that flush_pending_unlocked()
>                                                                  // is observed here? So that signal list isn't messed up
>                                                                  // pid_task() doesn't have acquire semantics


On some far fetched completely out of order CPU that might be possible,
but it's moot as it's already established that we can't do that lockless
at this point.