Re: [PATCH] signal: Prevent exec() race
From: Frederic Weisbecker
Date: Tue Sep 01 2026 - 09:34:38 EST
Le Tue, Sep 01, 2026 at 02:55:02PM +0200, Thomas Gleixner a écrit :
> 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.
Sorry I probably missed something in the discussion, what can't we do
lockless?
Thanks.
--
Frederic Weisbecker
SUSE Labs