Re: Race between vmtruncate and mapped areas?

Andrea Arcangeli (andrea@suse.de)
Sat, 17 May 2003 19:29:42 +0200


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/