All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: huangpei@loongson.cn
Cc: Paul Burton <paul.burton@mips.com>,
	"stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"akiyks@gmail.com" <akiyks@gmail.com>,
	"andrea.parri@amarulasolutions.com" 
	<andrea.parri@amarulasolutions.com>,
	"boqun.feng@gmail.com" <boqun.feng@gmail.com>,
	"dlustig@nvidia.com" <dlustig@nvidia.com>,
	"dhowells@redhat.com" <dhowells@redhat.com>,
	"j.alglave@ucl.ac.uk" <j.alglave@ucl.ac.uk>,
	"luc.maranget@inria.fr" <luc.maranget@inria.fr>,
	"npiggin@gmail.com" <npiggin@gmail.com>,
	"paulmck@linux.ibm.com" <paulmck@linux.ibm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	Huacai Chen <chenhc@lemote.com>
Subject: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage
Date: Thu, 25 Apr 2019 11:09:07 +0200	[thread overview]
Message-ID: <20190425090907.GB14281@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20190425073348.GV11158@hirez.programming.kicks-ass.net>

On Thu, Apr 25, 2019 at 09:33:48AM +0200, Peter Zijlstra wrote:

> > Let me explain the bug more specific:
> > 
> > the bug ONLY matters in following situation:
> > 
> > #. more than one cpu (assume cpu A and B) doing ll/sc on same shared
> > var V
> > 
> > #. speculative memory access from A cause A erroneously succeed sc
> > operation, since the erroneously successful sc operation violate the
> > coherence protocol. (here coherence protocol means the rules that CPU
> > follow to implement ll/sc right)
> > 
> > #. B succeed sc operation too, but this sc operation is right both
> > logically and follow the coherence protocol, and makes A's sc wrong
> > logically since only ONE sc operation can succeed.
> 
> (I know your coherence protocol is probably more complicated than MESI,
> but bear with me)
> 
> So A speculatively gets V's line in Exclusive mode, speculates the Lock
> flag is still there and completes the Store. This speculative store then
> leaks out and violates MESI because there _should_ only be one Exclusive
> owner of a line (B).
> 
> Something like that?

So B gets E (from LL), does I on A, then SC succeeds and get M.  A got
I, speculates E, speculates M and lets the M escape.

That gets us with 2 competing Ms (which is of course completely
insane), one wins one looses (at random I presume).

And this violates atomic guarantees because one operation got lost.

> > If it is not LL/SC but other memory access from B on V, A's ll/sc can
> > follow the atomic semantics even if A violate the coherence protocol
> > in the same situation.
> 
> *shudder*...
> 
>   C atomic-set
> 
>   {
> 	  atomic_set(v, 1);
>   }
> 
>   P1(atomic_t *v)
>   {
> 	  atomic_add_unless(v, 1, 0);
>   }
> 
>   P2(atomic_t *v)
>   {
> 	  atomic_set(v, 0);
>   }
> 
>   exists
>   (v=2)
> 
> So that one will still work? (that is, v=2 is forbidden)

But then in this case, P1 has E from LL, P2 does M from the STORE, which
should cause I on P1. P1 speculates E, speculates M and lets M escape.

We again have two competing Ms, one wins at random, and v==2 if P1
wins. This again violates the atomic guarantees and would invalidate
your claim of it only mattering for competing LL/SC.

Or am I missing something? (quite likely, I always get confused with
these things)

  reply	other threads:[~2019-04-25  9:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24 12:36 [RFC][PATCH 0/5] atomic: Fixes to smp_mb__{before,after}_atomic() and mips Peter Zijlstra
2019-04-24 12:36 ` [RFC][PATCH 1/5] mips/atomic: Fix cmpxchg64 barriers Peter Zijlstra
2019-04-24 21:00   ` Paul Burton
2019-04-25  6:59     ` Peter Zijlstra
2019-04-24 12:36 ` [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage Peter Zijlstra
2019-04-24 12:59   ` Peter Zijlstra
2019-04-24 21:18   ` Paul Burton
2019-04-25  4:58     ` huangpei
2019-04-25  7:33       ` Peter Zijlstra
2019-04-25  9:09         ` Peter Zijlstra [this message]
2019-04-25 12:14           ` huangpei
2019-04-25  9:12         ` Peter Zijlstra
2019-05-14 15:58           ` Peter Zijlstra
2019-05-14 16:10             ` Linus Torvalds
2019-05-14 16:56               ` Peter Zijlstra
2019-05-14 17:07                 ` Linus Torvalds
2019-05-15 13:50               ` huangpei
2019-04-25 11:32         ` huangpei
2019-04-25 12:26           ` Peter Zijlstra
2019-04-25 12:51             ` huangpei
2019-04-25 13:31               ` Peter Zijlstra
2019-04-26  2:57                 ` huangpei
2019-05-14 15:46                   ` Peter Zijlstra
2019-04-25 16:12       ` Linus Torvalds
2019-04-25  7:15     ` Peter Zijlstra
2019-04-24 12:36 ` [RFC][PATCH 3/5] mips/atomic: Optimize loongson3_llsc_mb() Peter Zijlstra
2019-04-24 12:37 ` [RFC][PATCH 4/5] mips/atomic: Fix smp_mb__{before,after}_atomic() Peter Zijlstra
2019-04-24 21:24   ` Paul Burton
2019-04-25  7:34     ` Peter Zijlstra
2019-04-24 12:37 ` [RFC][PATCH 5/5] x86/atomic: " Peter Zijlstra
2019-04-24 13:41   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190425090907.GB14281@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akiyks@gmail.com \
    --cc=andrea.parri@amarulasolutions.com \
    --cc=boqun.feng@gmail.com \
    --cc=chenhc@lemote.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=huangpei@loongson.cn \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=paul.burton@mips.com \
    --cc=paulmck@linux.ibm.com \
    --cc=stern@rowland.harvard.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.