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 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).
>>>
>>> Is you argument that sigfillset already does this, and there is no way
>>> to compute the complement of a signal set, so the bits for
>>> SIGCANCEL and SIGSETXID can never become set?
>>
>> Yes.
>>
>>>
>>> I think it's possible to set them directly using sigaddset. I don't see
>>> why using SIGCANCEL/SIGSETXID with that function would be undefined.
>>
>> sigaddset filter out SIGCANCEL/SIGSETXID through __is_internal_signal,
>> returning EINVAL for such case.
>
> Oh, I see.
>
> 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.