Re: [PATCH 1/2] linux: Reserve a new signal for SIGTIMER

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 04/01/2020 07:55, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 31/12/2019 16:41, Florian Weimer wrote:
>>> * Adhemerval Zanella:
>>>
>>>> The fix for BZ#10815 requires decouple SIGTIMER and SIGCANCEL.
>>>
>>> How so?  I don't see why, sorry.
>>>
>>
>> Indeed 'requires' is not the right word, since I added this patch to 
>> solve a different problem.  What about:
> 
> I think the premise is wrong.  Reserving another signal has backwards
> compatibility implications, and we should do not so lightly.  I just
> don't see the need to do this to address this bug.  There are better
> ways (like the patch I posted that disables signals around the clone
> call and pthread_create and automatically enables SIGCANCEL and thus
> SIGTIMER on the new thread as a side effect).
> 

The backwards compatibility might arise when application mixes rt-signals
and different libc version or if it hard-code signal numbers in some
ways or does not runtime check rt-signal allocation against SIGRTMAX
(such as tst-signal6.c). So I am not sure it is something we should
prevent do so (although I agree that it might not be a strong premise).

But I don't have a strong opinion about this, it seemed the 
straightforward change to fix BZ#10815 while still allowing thread 
cancellation.  I will send an updated version that explicit re-enable
SIGCANCEL on the SIGEV_THREAD (without decoupling SIGCANCEL and
SIGTIMER).  Once your patch is upstream, we can remove SIGCANCEL
handling on timer_routines.c.