Re: [PATCH] signal/posixtimers: Handle ignore/blocked sequences correctly

Thomas Gleixner
2024-12-20T14:59:56Z

On Fri, Dec 20 2024 at 14:23, Frederic Weisbecker wrote:
> Le Fri, Dec 20, 2024 at 02:14:07PM +0100, Thomas Gleixner a écrit :
>> On Fri, Dec 20 2024 at 14:06, Frederic Weisbecker wrote:
>> > Le Thu, Dec 19, 2024 at 08:46:25PM +0100, Thomas Gleixner a écrit :
>> >> if (!list_empty(&q->list)) {
>> >> /*
>> >> - * If task group is exiting with the signal already pending,
>> >> - * wait for __exit_signal() to do its job. Otherwise if
>> >> - * ignored, it's not supposed to be queued. Try to survive.
>> >> + * The signal was ignored and blocked. The timer
>> >> + * expiry queued it because blocked signals are
>> >> + * queued independent of the ignored state.
>> >> + *
>> >> + * The unblocking set SIGPENDING, but the signal
>> >> + * was not yet dequeued from the pending list,
>> >> + * which would have put it back on the ignore list.
>> >
>> > I must be missing something. I don't see dequeue_signal() checking if a signal
>> > is ignored upon delivery.
>>
>>
>> Sorry, I meant get_signal() which is what the actual signal delivery
>> path on exit to user space invokes. dequeue itself does not care.
>>
> Hmm, ok it eventually ignores the signal delivery to the user but:
>
> _ Dequeue signal has delivered it to posix timers
> _ The signal isn't moved back to the ignored list (or I'm missing something else?)

Hmm. Right it is not, but that's correct for blocked signals because
they can be also retrieved by sig[timed]wait().

For the case where the signal is ignored, the dequeue and posix timer
delivery is not harmful. If it gets rearmed, then the next timer expiry
will see ignored and move it to the ignored list.

Let me stare at it some more and rewrite the comments to match reality.

Thanks for pointing it out!

tglx