Re: [PATCH v2] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

[Paul E. McKenney]

On Fri, Jul 13, 2018 at 07:58:25PM -0700, Linus Torvalds wrote:
> On Fri, Jul 13, 2018 at 6:51 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > The point being that the scenarios under discussion in this thread all
> > fall most definitely into the "Non-standard usage; you'd better know
> > exactly what you're doing" category.
> 
> Well, yes and no.
> 
> The thing is, people expected unlock+lock to give a memory ordering.
> It happened in RCU, and it's happened before elsewhere.

True enough.  I have grown quite used to the current unlock+lock ordering,
but yes, it did come as a bit of a surprise when I first came across it
some years back.  And it took quite a bit of digging to work out what
was going on.  My hope is of course that whatever the eventual choice,
having the memory model in place will make it easier for developers down
the line.

> So it *is* the "pure locking" thing that ends up confusing people.
> Yes, you have some other access that then cares about the memory
> ordering, but this is a fairly natural expectation to have
> (considering that we've had the same issue before).

That said, I was doing (and am still doing) some pretty unusual things
with RCU.  It requires every access from any CPU before any given grace
period to be ordered before any access from any CPU after that same
grace period.  That sort of requirement has been rare enough that the
smp_mb__after_unlock_lock() macro RCU uses is defined locally within RCU,
and is currently used only by RCU.

But as always, your kernel, your choice!

							Thanx, Paul