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 14:59, Zack Weinberg wrote:
> 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))`.
In this case we will to either keep the current semantic or remove any
filter in sigprocmark, sigemptyset, sigfillset, sigaddset, and sigdelset.
>
>>> 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.
In fact, the static / memset initialization is a point that made me
realize that there is no much gain in this change. I think it is
better to withdrew this patch.