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 16:05, Adhemerval Zanella wrote:
>
>
> 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.
>
Maybe an option should be to explicit return EINVAL if user tries to
set any internal signal instead of silent removed it and issue
the sigprocmask?