Re: [patch v6 17/20] signal: Queue ignored posixtimers on ignore list

[Thomas Gleixner <tglx@linutronix.de>]

On Fri, Nov 01 2024 at 15:21, Frederic Weisbecker wrote:
> Le Thu, Oct 31, 2024 at 04:46:43PM +0100, Thomas Gleixner a écrit :
>> +static void sigqueue_free_ignored(struct task_struct *tsk, struct sigqueue *q)
>> +{
>> +	if (likely(!(q->flags & SIGQUEUE_PREALLOC) || q->info.si_code != SI_TIMER))
>> +		__sigqueue_free(q);
>> +	else
>> +		posixtimer_sig_ignore(tsk, q);
>
> So this happens when the signal is ignored and delays it to when it will be
> unignored. But the comment on do_sigaction() says:
>
> 		/*
> 		 * POSIX 3.3.1.3:
> 		 *  "Setting a signal action to SIG_IGN for a signal that is
> 		 *   pending shall cause the pending signal to be discarded,
> 		 *   whether or not it is blocked."
> 		 *
> 		 */
>
> Are posix timers an exception to that rule?
>
> Also I see flush_sigqueue_mask() called on other occasions, for example
> when a STOP signal happens to remove pending CONT, not sure if posix
> timers can set SIGCONT...

No. The problem with posix timers is that they are magically different
from regular signals in the case of periodic timers.

When the signal is ignored at expiry, then the signal is not delivered
and is 'dropped'. But when SIG_IGN is removed then the following period
expiry has to deliver the signal.

Right now the kernel ensures that by keeping the timer self rearming and
rate limiting it for obvious reasons. That's a completely pointless
exercise up to the point where SIG_IGN is removed.

The only way to avoid the self rearming is to actually stop the timer
when the signal is ignored and rearm it when SIG_IGN for the specific
signal is removed.

That's what this magic does...

Thanks,

        tglx