* Paul E. McKenney [off-list ref] wrote:

On Sun, Jan 15, 2017 at 10:40:58AM +0100, Ingo Molnar wrote:

quoted

* Paul E. McKenney [off-list ref] wrote:

quoted

quoted

[sounds of rummaging around in the Git tree]

I found this commit of yours from ancient history (more than a year ago!):

  commit 12d560f4ea87030667438a169912380be00cea4b
  Author: Paul E. McKenney [off-list ref]
  Date:   Tue Jul 14 18:35:23 2015 -0700

    rcu,locking: Privatize smp_mb__after_unlock_lock()
    
    RCU is the only thing that uses smp_mb__after_unlock_lock(), and is
    likely the only thing that ever will use it, so this commit makes this
    macro private to RCU.
    
    Signed-off-by: Paul E. McKenney [off-list ref]
    Cc: Will Deacon [off-list ref]
    Cc: Peter Zijlstra [off-list ref]
    Cc: Benjamin Herrenschmidt [off-list ref]
    Cc: "linux-arch@vger.kernel.org" [off-list ref]

So I concur and I'm fine with your patch - or with the status quo code as well.

I already have the patch queued, so how about I keep it if I get an ack
from the powerpc guys and drop it otherwise?

Yeah, sounds good! Your patch made me look up 'RelAcq' so it has documentation 
value as well ;-)

;-) ;-) ;-)

Looking forward, my guess would be that if some other code needs
smp_mb__after_unlock_lock() or if some other architecture needs
non-smb_mb() special handling, I should consider making it work the
same as smp_mb__after_atomic() and friends.  Does that seem like a
reasonable thought?

Yeah, absolutely - it's just that the pattern triggered the 'this looks a bit too 
specialized' response in me, but after seeing the details (again ...) I agree that 
this time is different!

Thanks,

	Ingo