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

[Will Deacon <will dot deacon at arm dot com>]

On Fri, Nov 11, 2016 at 11:33:38AM +0000, Ramana Radhakrishnan wrote:
> On Fri, Nov 11, 2016 at 5:13 AM, Torvald Riegel <triegel@redhat.com> 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
> 
> 
> atomic-machine.h for arm was rewritten to use the __atomic builtins a
> few years back. Thus if userland compiled these at architecture levels
> less than the architecture levels where these could be inlined, the
> emulation would be through calls to kernel helper pages. It is my
> understanding the kernel helper routines if running on MP systems that
> had the ldrex / strex instructions the kernel would use those to
> implement CAS. Furthermore I don't know of any SMP systems that didn't
> have the LDREX / STREX instructions thus I don't think that ARM is
> affected by this. CC'ing Will and Catalin for a more definitive
> answer.

That's correct. The only other case is where you get pre-empted in the
critical section on a UP platform without LDREX/STREX, but the kernel
handles that.

Will