This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: arm, hppa, m68k, sh, nios maintainers: Please check your emulation of atomic operations


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]