Messages in this thread |  | | | Date | Sat, 17 May 2003 19:29:42 +0200 | | From | Andrea Arcangeli <> | | Subject | Re: Race between vmtruncate and mapped areas? |
| |
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/
|  |