[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241207050115.GP10433@brightrain.aerifal.cx>
Date: Sat, 7 Dec 2024 00:01:15 -0500
From: Rich Felker <dalias@...c.org>
To: JinCheng Li <naiveli233@...look.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>,
Markus Wichmann <nullplan@....net>
Subject: Re: Do we need to enhance robustness in the signal mask?
On Fri, Dec 06, 2024 at 01:24:20PM +0000, JinCheng Li wrote:
> 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.
As I've said repeatedly, this can't be solved in
pthread_sigmask/sigprocmask. There are ways to install sigsets that
don't go thru this path. Either we need to make it so there's no way
to get a (valid, non-UB) sigset_t with SIGTIMER unblocked, or we just
need to make it so it doesn't matter if it's unblocked or so unblocked
is the desired state. The latter approach looks like it fixes other
things too.
Rich
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.
