This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/4] nptl: Fix Race conditions in pthread cancellation, (BZ#12683)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>
- Date: Fri, 19 Sep 2014 21:38:40 +0000
- Subject: Re: [PATCH 1/4] nptl: Fix Race conditions in pthread cancellation, (BZ#12683)
- Authentication-results: sourceware.org; auth=none
- References: <541C2901 dot 1050609 at linux dot vnet dot ibm dot com> <541C2DC8 dot 3010505 at linux dot vnet dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1409191646050 dot 11496 at digraph dot polyomino dot org dot uk>
On Fri, 19 Sep 2014, Joseph S. Myers wrote:
> For cases like this, it seems to me that you should be able to do a
> preliminary patch that defines SYSCALL_CANCEL in a way that expands to the
> existing code using LIBC_CANCEL_ASYNC, INLINE_SYSCALL and
> LIBC_CANCEL_RESET. If you can define some of the new macros like that,
> then you can change most or all such code for all architectures to the new
> idiom (reasonably safely without being able to test on all the
> architectures), reducing the size of the per-architecture patches needed
> later and of the patches with the changes that actually fix the main
> issue.
Also, if the function in question has a "Consider moving to
syscalls.list." comment (as in
sysdeps/unix/sysv/linux/powerpc/powerpc64/pread.c, for example), then if
in fact everything that C function does is equivalent to something that
can be represented in syscalls.list, doing that move (part of bug 14138)
would serve equally well for this purpose. (For your patch series, of
course only the part of bug 14138 dealing with functions with cancellation
handling is relevant.)
--
Joseph S. Myers
joseph@codesourcery.com