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

[Thomas Gleixner <tglx@kernel.org>]

On Thu, Aug 27 2026 at 13:43, Eric W. Biederman wrote:
> Thomas Gleixner <tglx@kernel.org> writes:
>> The safe and obvious place is to do that is _after_ setting
>> task::sighand to NULL because that ensures that no new signal can be
>> queued and nothing can touch task::pending anymore.
>
> Not really.  Using release_task (which is what is called when a zombie
> is reaped) for anything except cleaning up state that a zombie needs is
> a bit of a misfeature.  Timers should not be active in a zombie.
> Signals also should be deactivated long before then.

I agree.

>
> The obvious place to clean up task::pending i.e. signals is in
> exit_signals().
>
> I expect if I read through the history again that I would find that
> exit_signals() used to call flush_sigqueue, and that during the addition
> of posix thread signal handling flush_sigqueue was moved into
> __exit_signal in release_task because knowing if the entire thread group
> is dead was not available during that part of 2.5.
>
> We should honor PF_EXITING on a task and simply stop delivering
> signals to it.  Today the code goes halfway there and does not
> set sig-pending after PF_EXITING is set.

If flushing tsk::pending in exit_signals() is safe and stopping signals
to be queued when PF_EXITING is observed under sighand lock, then sure
that's the right thing to do. I'll look into that tomorrow.

> There is the goofy case that we need to be able to deliver signals
> to the entire process through a zombie thread (in particular a zombie
> thread group leader).  That goofy case unfortunately means that except
> for signals to just the thread we have to deliver signals when
> PF_EXITING is set.  That goofy case also unfortunately means that
> sighand_struct needs to be retained past the point where signals
> are delivered.

There's a lot of goofy stuff in this code :)

Thanks

        tglx