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

[Joseph Myers <joseph at codesourcery dot com>]

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.

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).

-- 
Joseph S. Myers
joseph@codesourcery.com