Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)

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

On 18-09-2015 10:40, Joseph Myers wrote:
> On Fri, 18 Sep 2015, Adhemerval Zanella wrote:
> 
>> This should be the same as the non-thread version for non-rtld:
>>
>> long int
>> __syscall_cancel (__syscall_arg_t nr, __syscall_arg_t arg1,
>>                   __syscall_arg_t arg2, __syscall_arg_t arg3,
>>                   __syscall_arg_t arg4, __syscall_arg_t arg5,
>>                   __syscall_arg_t arg6)
>> {
>>   INTERNAL_SYSCALL_DECL (err);
>>   result = INTERNAL_SYSCALL_NCS (nr, err, 6, a1, a2, a3, a4, a5, a6);
>>   if (INTERNAL_SYSCALL_ERROR_P (result, err))
>>     return -INTERNAL_SYSCALL_ERRNO (result, err);
>>   return result;
>> }
> 
> What should the interfaces to this and related functions / macros be in 
> the case where syscall returns are wider than "long" (this needs 
> documenting on the wiki page, of course)?  Take the case of lseek for x32 
> or MIPS n32, for example; it's listed as a cancellation point in 
> sysdeps/unix/sysv/linux/wordsize-64/syscalls.list and 
> sysdeps/unix/sysv/linux/mips/mips64/syscalls.list (though not for 32-bit; 
> I'm not clear on the reason for the inconsistency).  And those use the 
> plain 64-bit syscall for ILP32 ABIs; that is, returned values may exceed 
> the 32-bit range.

I see for such cases the port would need to provide extra implementation
for such symbols in the case (as the fstat for x32 does).  I see this a
better approach, but I am open to suggestions.

And for lseek we need to define for GLIBC if this function is indeed a
cancellation entrypoint of not and make it consistent for all architectures
(and POSIX states it an optional one [1]).

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_05_02

> 
> Those syscalls don't of course work reliably when the C macros are used at 
> present, because the C macros use long or unsigned long for the result 
> (and I don't know what GCC does with results outside the relevant range 
> stored in a register variable of that type, but for MIPS it's 
> architecturally undefined what the results are of 32-bit operations on a 
> register that's not properly sign-extended to 64-bit).  But if the 
> complete function implementation uses the assembly macros, which is the 
> case for lseek, it should work fine.  However, for cancellable syscalls 
> you're now going through C functions using type long, and so potentially 
> losing the high part of the return value.
> 
> Maybe lseek could be solved by making it not cancellable unless there's a 
> good reason for the inconsistency, but all other syscalls listed as 
> cancellable in syscalls.list would still need reviewing to make sure they 
> don't have problems, unless a cleanup is done to use a better type than 
> "long" for syscall returns in architecture-independent code and code for 
> architectures supporting 64-bit returns with ILP32 ABIs (which seems 
> logically cleaner, but more work).
> 

One way is to make the return syscall another type like __syscall_arg_t
and make the specific implementation for such ports to redefine it to
a better one if it is required.