This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 5/7] linux: Remove SIGCANCEL/SIGSETXID handling on sigprocmask
On Thu, Dec 12, 2019 at 8:44 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 12/12/2019 10:12, Florian Weimer wrote:
> > * Adhemerval Zanella:
> >
> >> On 12/12/2019 09:54, Florian Weimer wrote:
> >>> * Adhemerval Zanella:
> >>>
> >>>> The sigfillset already does it, and this is the canonical way to operate
> >>>> on sigset_t. The only way to actually broke this assumption is if caller
> >>>> initialize sigset with memset or something similar, i.e, bypassing glibc
> >>>> (and again this is not a valid construction).
I think it would be appropriate for us to guarantee that `memset(s, 0,
sizeof(sigset_t))` has the same effect as `sigemptyset(s)`, because I
bet there is real code that does that, probably without realizing it's
technically wrong (e.g. by using memset to wipe an entire struct
sigaction and then not bothering to do a separate sigemptyset on
sa_mask, or by statically allocating a sigset_t and assuming that
zero-initialization will produce the same effect as sigemptyset).
But that argument doesn't apply to `memset(s, 0xFF, sizeof(sigset_t))`.
> > It's still not clear to me whether it is not in fact better to allow
> > appplications to block internal signals (from a compatibility
> > perspective, e.g. if the application knows that the stack pointer is
> > problematic).
>
> My view is the semantic of the signals are not exported to userspace
> (we could use a different signal for SIGCANCEL in a future version,
> for instance) and we can eventually phase out the signal usage if
> either POSIX deprecate some functionality or if kernel provides a
> cleanly way to accomplish the required functionality (for instance,
> if it provides a syscall that change the xid of all threads).
>
> Application can still block internal signals, but they will to actually
> statically initialize a sigprocmask in a non standard way.
This seems like a larger discussion that shouldn't hold up this patch.
Status quo is that blocking SIGCANCEL and SIGSETXID is not supported,
and the patch doesn't change that.
zw