This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix __libc_signal_block_all on sparc64
On 05/12/2019 14:05, Florian Weimer wrote:
> * 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.
I think we can use something like:
static const sigset_t sigall_set =
{ .__val = {[0 ... _SIGSET_NWORDS-1 ] = -1 } };
It would give compiler/linker more information to remove duplicate
definitions.
>
>> 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.
I think for sigfillset there is no much gain in allowing all signals,
blocking the internal ones adds some consistency at least.