This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]