Re: [PATCH v6 4/5] MCS Lock: Barrier corrections

[Thomas Gleixner <tglx@linutronix.de>]

Linus,

On Tue, 26 Nov 2013, Linus Torvalds wrote:

> On Tue, Nov 26, 2013 at 2:51 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Good points, and after_spinlock() works for me from an RCU perspective.
> 
> Note that there's still a semantic question about exactly what that
> "after_spinlock()" is: would it be a memory barrier *only* for the CPU
> that actually does the spinlock? Or is it that "third CPU" order?
> 
> IOW, it would stil not necessarily make your "unlock+lock" (on
> different CPU's) be an actual barrier as far as a third CPU was
> concerned, because you could still have the "unlock happened after
> contention was going on, so the final unlock only released the MCS
> waiter, and there was no barrier".
> 
> See what I'm saying? We could guarantee that if somebody does
> 
>     write A;
>     spin_lock()
>     mb__after_spinlock();
>     read B
> 
> then the "write A" -> "read B" would be ordered. That's one thing.
> 
> But your
> 
>  -  CPU 1:
> 
>     write A
>     spin_unlock()
> 
>  - CPU 2
> 
>     spin_lock()
>     mb__after_spinlock();
>     read B
> 
> ordering as far as a *third* CPU is concerned is a whole different
> thing again, and wouldn't be at all the same thing.
> 
> Is it really that cross-CPU ordering you care about?

Depends on the use case. In the futex case we discussed in parallel we
very much care about that

     w[A]      |     w[B]
     mb	       |     mb
     r[B]      |     r[A]

provides the correct ordering. Until today the spinlock semantics
provided that.

I bet that more code than the cursed futexes is relying on that
assumption.

RCU being one example I'm aware of. Though RCU is one of the simple
cases where the maintainer is actually aware of the problem and
indicated that he is willing to adjust it.

Though I doubt that other places which silently rely on that ordering,
have the faintest clue why the heck it works at all.

I'm all for the change, but we need to be painfully aware of the
lurking (hard to decode) wreckage ahead.

Thanks,

	tglx

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>