eieio in atomics

[Anton Blanchard]

Hi Dave,

> I see that you added an eieio in atomic operations in the 2.5 tree.
> Can you shed some light on what was discovered here?  I thought these
> were not required to imply a memory barrier.  Was an actual problem
> hit and do we need a fix put into the 2.4 code base?

I started looking through the memory barriers in the kernel and
was worried about places where atomics were used as reference counts:

	foo->value = 1;
	if (!atomic_dec_and_test(&foo->refcnt))
		kfree(foo);

If we do this on two cpus, we need to make sure the first instruction
does not end up moving down past the atomic operation. The window
would be small, the isync at the end of the atomic would prevent
it from moving any further down, so the window would be the few
instructions between the successful store conditional and the isync.

Having said that I havent convinced myself 100% that the race is real.

My current understanding is that atomics and bitops that do not return
values imply no memory barrier, but a memory barrier is implied for
ones that return values.

I started looking for operations that may imply memory barriers,
below is a summary of the ones I found so far. The PA RISC and MIPS
maintainers are interested in sorting this mess out, as are the SGI
IA64 guys wrt IO barriers.

Anton

atomics
        with return values
        without return values
        smp_mb__{before|after}_atomic_{dec|inc}

bitops
        with return values
        without return values
        smp_mb__{before|after}_clear_bit

xchg*
cmpxchg*

mb
rmb
wmb

smp_mb
smp_rmb
smp_wmb

in*
out*

read*
write*

ppc specific:
	iobarrier_rw
	iobarrier_r
	iobarrier_w
	iosync

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/