[PATCH v6 07/13] ARC: Linux Syscall Interface

[Vineet Gupta]

On 6/3/20 1:04 PM, Adhemerval Zanella via Libc-alpha wrote:
> 
> 
> On 03/06/2020 16:46, Vineet Gupta wrote:
>> On 5/29/20 9:49 AM, Adhemerval Zanella via Libc-alpha wrote:
>>>> +	; ----- child starts here ---------
>>>> +
>>>> +	; Setup TP register (only recent kernels v4.19+ do that)
>>>> +	and.f	0, r12, CLONE_SETTLS
>>>> +	mov.nz	r25, r9
>>> Do you still need to set it since the minimum supported kernel
>>> for ARC is 5.1 ?
>>
>> Right.
>>
>>> It should be safe for internal glibc usage, since for both pthread
>>> and posix_spawn it blocks all signals including SIGCANCEL and SIGXID.
>>> However this is still small race window if this is called directly 
>>> with pthread cancellation or g*uid in multithread.
>>
>> I'm not sure what you mean above. Do you mean not doing this in glibc and even if
>> kernel support didn't exist should be safe internally ?
> 
> At least for internal clone usage with CLONE_VM within glibc we explicit
> disable all signals (posix_spawn and pthread_create).
> 
>>
>> fwiw as mentioned above kernel sets up TP for clone (SETTLS). I detested doing
>> that for a long time, give ABI implications but ended up doing it anyways due to
>> an actual race hit when running uClibc tst-kill6 [1]
> 
> We explicit disable all signals during the create_thread call in pthread_create
> (b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8), so it should not happen on glibc
> anymore.  However it is still an issue if application calls clone itself.

The scenario there was pthread_create() and parent getting scheduled before child
and immediately doing pthread_kill() causing child signal handler to be invoked
and signal handler doing pthread_self() which was broken as TP was not setup.

With commit above, parent pthread_kill() will block and will only run when child
is scheduled and unblocks the signals !