This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 18 Sep 2015 10:15:44 -0300
- Subject: Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)
- Authentication-results: sourceware.org; auth=none
- References: <55FB1CA0 dot 2 at linaro dot org> <alpine dot DEB dot 2 dot 10 dot 1509172032090 dot 2455 at digraph dot polyomino dot org dot uk> <alpine dot DEB dot 2 dot 10 dot 1509172102550 dot 2455 at digraph dot polyomino dot org dot uk>
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.