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

[Eric W. Biederman]

Oleg Nesterov <oleg@xxxxxxxxxx> writes:

> Thomas,
>
> I am already sleeping, but let me ask anyway
>
> On 08/26, Thomas Gleixner wrote:
>>
>> On Wed, Aug 26 2026 at 11:36, Oleg Nesterov wrote:
>> >
>> > So. With this change release_task()->flush_sigqueue(&old_leader->pending)
>> > can still race with posixtimer_send_sigqueue(), but it will do nothing.
>> >
>> > But it also does "nothing" if tmr->sigq is already pending (!list_empty)
>> > so I am starting to think about the change below again...
>>
>> Sure, but that's an orthogonal optimization once we fixed the exec()
>> mess :)
>
> I am almost sure I missed something again. But I thought that this "optimization"
> can also fix the exec() mess we discuss in this thread?
>
> No?

I haven't been through all of this in detail lately but I have a thought
about cleaning up the exec "mess".

Could the posix timers cleanup be moved from __exit_signal in
release_task (which is really for cleanup for zombies but has
been historically abused because it was the only place that
knew when the whole group was dead), into somewhere in do_exit?

Say near where hrtimers_cancel and exit_itimers are called.

Then perhaps move the posix timer disabling before de_thread?

I think that would allow ignoring the whole exchange_tids
aspect of things because the timers would simply not be running.

I think that would make a good general cleanup as well as avoiding
the craziness of moving thread ids.

I think.

Am I missing something that keeps that from working?

Is that change simply too much to contemplate to sort out this
situation?

Eric

p.s.  I wish years ago I had the energy to get glibc to stop assuming on
a newly started process that thread-id == process_id.  Then this
exchanging of id's on tasks could have been completely removed from the
kernel.  Oh well.