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

[Torvald Riegel]

On Fri, 2016-11-11 at 21:47 +0000, Will Deacon wrote:
> 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.

It might be good to add this fact as a comment to atomic-machine.h, so
that future developers will know about this.