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

[Thomas Gleixner <tglx@kernel.org>]

On Wed, Aug 26 2026 at 21:32, Oleg Nesterov wrote:
> 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?

It does not because the sigqueue stays linked in old_leader::pending and
any concurrent or later access to it from an expiry (see Hyunwoo's
explanation) will access freed memory: either old_leader::pending or
other unrelated sigqueue entries which have been freed.

I really don't understand why you are so obsessed about "fixing" it with
a dirty hack instead of just making it comprehensible, safe and future
proof in the first place.

I'm actually tempted to move the posix timer cleanup _before_
de_thread() and just make sure that no new timers can be created anymore.

Thanks,

        tglx