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

[Adhemerval Zanella]

On 17-09-2015 18:07, Joseph Myers wrote:
> On Thu, 17 Sep 2015, Joseph Myers wrote:
> 
>> Do you mean INLINE_SYSCALL (setting errno, returning -1 on error) or 
>> INTERNAL_SYSCALL?  If INTERNAL_SYSCALL, what exactly are the semantics for 
>> architectures such as MIPS that use two registers for returns (with a 
>> separate register for an error flag, and the normal return register having 
>> the non-negated syscall number in that case)?  I didn't spot any such 
>> architectures in the examples you'd already converted - if I missed any, 
>> it would be helpful for your instructions for architecture maintainers to 
>> point explicitly to the already-converted architectures that provide the 
>> most generic examples for each of the two syscall return conventions.
> 
> On further investigation, it seems powerpc is such an architecture you've 
> already converted (but the accurate documentation of semantics, with 
> pointers to the most generic examples, is still definitely needed).  But 
> the patch division is really confusing.  Patch 2 says "powerpc64", but it 
> actually includes loads of architecture-independent changes.  Patch 6 says 
> "ppc32", but it actually includes an i386 change.  

The problem in this case powerpc64 and powerpc32 included code that are
from other ports (which I think it is not a good approach, but we can
cleanup later). For instance:

$ cat sysdeps/unix/sysv/linux/powerpc/powerpc32/fcntl.c
#include <sysdeps/unix/sysv/linux/i386/fcntl.c>

And I organized with powerpc as first because back in time it was the architecture
I stated to work with.

> To the extent that the 
> patches will all go in one commit anyway, could you use a division into 
> patches that more logically reflects the different parts of the change.  
> (To the extent that patches can go in separate commits - Phil Blundell's 
> new tests come to mind, unless there's some reason they depend on other 
> changes - they should be posted and reviewed separately so they can go in 
> before the rest of the patch series.)
> 

Ok, I will create a patch to include Phil's new testscase.  For the rest of
patchset since it require very internal changes I see the architecture
approach of fixing each one with one patch a better approach than add
platform neutral patches that let the tree broken for all architectures.