Re: [PATCH] Fix __libc_signal_block_all on sparc64

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 05/12/2019 11:45, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> Where SIGALL_SET is defined as:
>>>
>>>   ((__sigset_t) { .__val = {[0 ...  _SIGSET_NWORDS-1 ] =  -1 } })
>> 
>> Shouldn't this refer to a global constant data object?  Then we wouldn't
>> have to emit many local copies of the same object and then copy it onto
>> the stack.
>> 
>> (GCC cannot know that the system call will not modify the object.)
>
> Do we really need to add a sigset_t object on ld (it won't require it
> any longer since you sent a reverted patch to the signal block on dlopen),
> libc, and libpthread?

It's already there, see the .LC0 label.  GCC should be using memset
instead of memcpy for the initialization, but it currently does not.

> In fact I think we can simplify it a bit an just get rid of these
> block/unblock signals and just use sigprocmask directly. I haven't done
> on posix_spawn because the sigprocmask semantic cleared the internal
> signals prior issuing rt_sigprocmask. 
>
> However 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 imho).

Another alternative would be to remove the restriction on blocking
internal signals altogether.  I don't think this would be very
problematic for SIGCANCEL.  For SIGSETXID, I think the code would just
block in the setxid caller due to the missing futex wakeup, and not
continue to run with partially unchanged credentials in case of a
blocked SIGSETXID signal on some thread.

Thanks,
Florian