Re: Race between vmtruncate and mapped areas?

[Andrea Arcangeli <andrea@suse.de>]

On Fri, May 16, 2003 at 05:27:25PM -0700, Daniel McNeil wrote:
> On Thu, 2003-05-15 at 16:17, Andrea Arcangeli wrote:
> 
> > no, the spin_lock only acts as a barrier in one way, not both ways, so
> > an smp_something is still needed.
> > 
> 
> Can you explain this more?  On a x86, isn't a spin_lock a lock; dec
> instruction and the rmb() a lock; addl.  I thought x86 instructions
> with lock prefix provided a memory barrier.

spin_lock yes on x86, but spin_unlock isn't a two way barrier even on
x86. Other archs like ia64 have special ways to declare the direction of
the barrier so they can do it for spin_lock too, not only for
spin_unlock like on the x86.

In short stuff outside the critical section can anways enter inside
unless a full mb() is executed either before or after the
spin_lock/spin_unlock. Never rely on a single spin_lock/spin_unlock to be a mb().

In short:

	spin_lock
	spin_unlock

is a mb().

But:

	spin_unlock
	spin_lock

is not an mb (and the above is what we have in our code, and this is why
I had to add the mb(), of course we just agreed it can be reduced to
smp_rmb()).

Andrea