[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z09LYnd-u6e8PFbv@voyager>
Date: Tue, 3 Dec 2024 19:18:10 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Do we need to enhance robustness in the signal mask?
Am Tue, Dec 03, 2024 at 09:44:10AM -0500 schrieb Rich Felker:
> There are only a limited number of ways you can get a sigset_t whose
> use with sigprocmask etc. doesn't have undefined behavior. Either you
> initialize it with sigemptyset or sigfillset then modify with
> sigaddset/sigdelset, or you get it from some interface that reads back
> a sigset_t.
>
You can get a valid sigset_t lacking SIGTIMER (unconditionally) with
pthread_sigmask(), and then set it, e.g like
sigset_t ss;
pthread_sigmask(SIG_SETMASK, 0, &ss);
pthread_sigmask(SIG_SETMASK, &ss, 0);
Honestly, this is close to the normal way to use pthread_sigmask(). The
same holds if the first all is used to block some other signal for some
reason and the second one then is supposed to restore the signal mask.
And you can do that in a timer notification function, where the signal
is supposed to be blocked. The timer thread will continue to execute
with the signal unblocked. And since the signal disposition is set to
SIG_DFL, and the default handling for RT signals is to terminate, the
next timer expiration will then kill the process.
> FWIW, SIGTIMER is not of special concern. It will never be generated
> except for timer threads, and these run with it explicitly blocked.
> This is very different from the situation for SIGCANCEL or SIGSYNCCALL
> where it's critical for arbitrary threads to be able to receive them.
> Also, at some point SIGTIMER is slated to be removed in favor of using
> clock_nanosleep for SIGEV_THREAD timers rather than kernelspace
> timers unless a strong reason not to do that is discovered.
I tried looking into doing that at some point and just gave up, because
of the overrun accounting. If I understand correctly, every timer
expiration between the notification being generated and being delivered
increases the overrun counter, and for each notification it is supposed
to be latched and then reset. So for SIGEV_THREAD, that would be every
expiration between the call and the return. And for SIGEV_SIGNAL, that
would be every expiration between the signal being sent and being
handled.
All of which was too complicated for me to wrap my head around, but
maybe you have more luck.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
