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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zya5wy9UyVo2cRvq@pavilion.home>
Date: Sun, 3 Nov 2024 00:46:11 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	John Stultz <jstultz@...gle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>, Stephen Boyd <sboyd@...nel.org>,
	Eric Biederman <ebiederm@...ssion.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [patch v6 17/20] signal: Queue ignored posixtimers on ignore list

Le Fri, Nov 01, 2024 at 09:47:15PM +0100, Thomas Gleixner a écrit :
> 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...


Agreed and that covers the case when the signal is queued while the handler
is SIG_IGN. But I didn't know about the case where the signal is queued and
then the handler is set to SIG_IGN before it get a chance to be delivered.
Which of course is not fundamentally different now that I think about it
twice.

And what about the other callers of flush_sigqueue_mask()? Such as SIGCONT
removed when SIGSTOP arrives? And the reverse as well? This moves the pending
timers signals to the ignore list until the signal is unignored, but in that
case SIGCONT is not ignored? Or perhaps SIGCONT and SIGSTOP can't be set for
posix timers?

Thanks.

> 
> Thanks,
> 
>         tglx
>