FYI, sporadic failure of rt/tst-timer-sigmask

[Adhemerval Zanella]

On 12/05/2020 11:35, Adhemerval Zanella wrote:
> 
> 
> On 12/05/2020 11:34, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> I could reproduce the issue by simulating some CPU load and i think the
>>> issue in fact related to Florian's b3cae39dcbf patch.
>>>
>>> The issue is the SIGTIMER is being received between pthread_create signal 
>>> unblocking after thread creation (nptl/pthread_create.c:418) and before 
>>> the timer helper thread blocks the SIGTIMER (timer_routines.c:144).  
>>> Since SIGTIMER is the same as SIGCANCEL, the sigcancel handler is triggered
>>> and it ignores the timer (the test sets a once-online timer to be triggered 
>>> in 0.001s).
>>>
>>> However it should not happen because the timer helper thread explicit
>>> masks off SIGTIMER/SIGCANCEL (timer_routines.c:146) on timer_helper_thread
>>> and it handles cancellation explicitly (timer_routines.c:109).
>>>
>>> This happen because on the mask it is restored by pthread_create.c
>>> after (nptl/pthread_create.c:418) the SIGCANCEL is explicitly added
>>> (nptl/pthread_create.c:772) even though the original signal mask has
>>> is explicit disabled (timer_routines.c:146).
>>>
>>> So we need a way to keep the SIGTIMER/SIGCANCEL masked on the 
>>> POSIX timer helper thread.
>>
>> Nice analysis.  I agree with it.  This interaction did not occur to me
>> when writing the pthread_create changes.

Yeah, it is not straightforward because the POSIX timer helper thread has
non standard semantic since it handles its own cancellation.  One option 
could to use a different signal to handle SIGTIMER, but if I recall 
correctly the last discussion about it you though it does not worth the 
possible ABI issues of increasing the SIGRTMIN value.

>>
>> I think I have a fix.  I'll post it once it builds. 8-)
> 
> Alright, thanks.
>