This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andreas Schwab <schwab at suse dot de>, Chung-Lin Tang <chunglin_tang at mentor dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 11 Nov 2016 14:32:53 -0500
- Subject: Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations
- Authentication-results: sourceware.org; auth=none
- References: <1478841215.7146.1031.camel@localhost.localdomain>
On 11/11/2016 12:13 AM, Torvald Riegel wrote:
> These architectures seem to all use various sorts of emulation for
> compare-and-exchange operations (CAS). If these emulations do not stop
> the world during a CAS, or do something else that prevents concurrent
> write operations to the same memory location as the CAS, then atomic
> store operations in glibc need to use a CAS to perform stores.
> Otherwise, concurrent stores can happen between the load(s) and the
> store that the CAS consists of.
>
> If your architecture is affected by this, then it may be possible that
> glibc's current concurrent code does not work correctly; this is because
> we may still have plain stores in places where atomic stores should be
> used. Once we have completed the conversion to C11 atomics, all
> concurrent stores will go through atomic_store_*().
> See Chris Metcalf's patch for tilepro:
> https://sourceware.org/ml/libc-alpha/2016-11/msg00414.html
>
> If your architecture is not affected, I suggest adding a comment why
> that is not the case.
This is an issue on hppa.
We need all concurrent stores to go through atomic_store_*().
The kernel light-weight syscall which emulates CAS can be interrupted by
another thread's store and thus break the CAS. The only thing we prevent
is a signal from the same thread interrupting the CAS, we do this by
not delivering the signal while the thread is in the CAS.
I'll fixup some of the atomic-machine.h bits to make sure we're doing
the most that we can to fix this.
--
Cheers,
Carlos.