[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SE1P216MB2484E83ED4752E151EEE65E89E312@SE1P216MB2484.KORP216.PROD.OUTLOOK.COM>
Date: Fri, 6 Dec 2024 13:24:20 +0000
From: JinCheng Li <naiveli233@...look.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
CC: Markus Wichmann <nullplan@....net>
Subject: Re: Do we need to enhance robustness in the signal mask?
Hi
> 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.
Maybe just judge the old sigset in pthread_sigmask, if SIGTIMER in old sigset is blocked, it should be in a timer thread, we can just block SIGTIMER whatever is set for SIGTIMER in new sigset. If SIGTIMER in old sigset is unblocked, just remain its status set by new sigset. As long as it is not in a timer thread, the status of SIGTIMER is unblocked or blocked doesn't affect anything.
Best,
JinCheng
________________________________
From: Markus Wichmann <nullplan@....net>
Sent: Friday, December 6, 2024 2:25
To: musl@...ts.openwall.com <musl@...ts.openwall.com>
Subject: Re: [musl] 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
Content of type "text/html" skipped
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.
