Re: Races in ARM atomicity.h functions?

[Alon Ziv <alonz at emblazesemi dot com>]

On Wednesday 19 May 2004 16:06, Daniel Jacobowitz wrote:
>
> I'm pretty sure you're right.  If you look at the list archives for
> around Feb. 2003 you can find a prior discussion of the issues.  I'm
> not sure that they're all fixable without changing the format of an
> atomic_t.

Well, these functions do not use atomic_t (just a "volatile long int").
I believe at least compare_and_swap can be fixed for the uses actually present 
in the glibc sources, by moving the "0:" label one line down:

static inline int
__attribute__ ((unused))
compare_and_swap (volatile long int *p, long int oldval, long int newval)
{
  int result, tmp;
  __asm__ ("\n"
	   "ldr\t%1,[%2]\n"
	   "0:\tmov\t%0,#0\n\t"
	   "cmp\t%1,%4\n\t"
	   "bne\t1f\n\t"
	   "swp\t%0,%3,[%2]\n\t"
	   "cmp\t%1,%0\n\t"
	   "swpne\t%1,%0,[%2]\n\t"
	   "bne\t0b\n\t"
	   "mov\t%0,#1\n"
	   "1:"
	   : "=&r" (result), "=&r" (tmp)
	   : "r" (p), "r" (newval), "r" (oldval)
	   : "cc", "memory");
  return result;
}

Since all compare_and_swap calls in glibc always use the same "oldval" value 
for a specific "p", the above code (IMO) will always work OK.

	-az