Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()

From	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()
Date	2015-07-16 17:20 +0200
Message-ID	<pMT73-22W-15@gated-at.bofh.it> (permalink)
References	(2 earlier) <pMlf3-3in-5@gated-at.bofh.it> <pMsqe-52Z-9@gated-at.bofh.it> <pMGMy-11H-15@gated-at.bofh.it> <pMJAJ-5aZ-1@gated-at.bofh.it> <pMJKq-5my-9@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, Jul 16, 2015 at 03:14:55PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > > the original worry we had about loads happening before the SC in lock.
> > 
> > However I think isync fixes *that* :-) The problem with isync is as you
> > said, it's not a -memory- barrier per-se, it's an execution barrier /
> > context synchronizing instruction. The combination stwcx. + bne + isync
> > however prevents the execution of anything past the isync until the
> > stwcx has completed and the bne has been "decided", which prevents loads
> > from leaking into the LL/SC loop. It will also prevent a store in the
> > lock from being issued before the stwcx. has completed. It does *not*
> > prevent as far as I can tell another unrelated store before the lock
> > from leaking into the lock, including the one used to unlock a different
> > lock.
> 
> Except that the architecture says:
> 
> <<
> Because a Store Conditional instruction may com-
> plete before its store has been performed, a condi-
> tional Branch instruction that depends on the CR0
> value set by a Store Conditional instruction does
> not order the Store Conditional's store with respect
> to storage accesses caused by instructions that
> follow the Branch
> >>
> 
> So isync in lock in architecturally incorrect, despite being what the
> architecture recommends using, yay !

Well, the architecture isn't expecting that crazies like myself would
want to have an unlock-lock provide ordering to some CPU not holding
the lock.  :-/

							Thanx, Paul

--
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/

Thread

[RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-13 14:20 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Peter Zijlstra <peterz@infradead.org> - 2015-07-14 10:40 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-14 12:10 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-14 21:40 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 03:40 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-15 13:00 +0200
          Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 15:20 +0200
  Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-15 05:10 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-15 12:50 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-16 04:10 +0200
        Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-16 17:20 +0200
          Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-07-17 01:00 +0200
            Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-17 11:40 +0200
              Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Peter Zijlstra <peterz@infradead.org> - 2015-07-17 12:20 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-17 14:50 +0200
              Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2015-07-18 00:20 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-20 15:40 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-20 15:50 +0200
                Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Will Deacon <will.deacon@arm.com> - 2015-07-20 16:00 +0200
    Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2015-07-15 16:20 +0200
      Re: [RFC PATCH v2] memory-barriers: remove  smp_mb__after_unlock_lock() Michael Ellerman <mpe@ellerman.id.au> - 2015-07-16 03:40 +0200

csiph-web