[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z1HwNqoIHPAoc8YD@voyager>
Date: Thu, 5 Dec 2024 19:25:58 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Do we need to enhance robustness in the signal mask?
Am Thu, Dec 05, 2024 at 12:56:44AM -0500 schrieb Rich Felker:
> One short-term fix that might be worth exploring is adding back a
> signal handler for SIGTIMER so it doesn't kill the process. The
> handler would just increment an "extra overruns" counter for the
> thread. It could only run during execution of the function, if the
> function unblocked the signal, since we would re-block the signal each
> time before the next sigwaitinfo.
>
> Rich
The easiest fix for the instant bug would probably be to just not mask
SIGTIMER out of the old signal mask returned by pthread_sigmask(). We
don't really care if it is blocked or not in most threads and explicitly
block it in the timer thread. This way, the signal just keeps its
blocking status forever in all other threads, and remains blocked in the
timer thread.
Side effect: Since SIGTIMER is 32, we can remove one masking instruction
on 32-bit architectures.
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.
