linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: huangpei@loongson.cn
To: "Peter Zijlstra" <peterz@infradead.org>
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: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage
Date: Thu, 25 Apr 2019 20:51:17 +0800 (GMT+08:00)	[thread overview]
Message-ID: <2ff11adc.c051.16a548cd90c.Coremail.huangpei@loongson.cn> (raw)
In-Reply-To: <20190425122611.GT4038@hirez.programming.kicks-ass.net>




> -----原始邮件-----
> 发件人: "Peter Zijlstra" <peterz@infradead.org>
> 发送时间: 2019-04-25 20:26:11 (星期四)
> 收件人: huangpei@loongson.cn
> 抄送: "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>
> 主题: Re: Re: Re: [RFC][PATCH 2/5] mips/atomic: Fix loongson_llsc_mb() wreckage
> 
> On Thu, Apr 25, 2019 at 07:32:59PM +0800, huangpei@loongson.cn wrote:
> 
> > > > 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);
> > >   }
> 
> This is the initial state.
> 
> > 
> > > 
> > >   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)
> > 
> > you mean C,P1, P2 on 3 different CPU? I do not know much about LKMM, can explain the test case more explicit?
> 
> The 'C' is the language identifier, the 'atomic-set' is the litmus name.
> 
> The unnamed block give the initial conditions.
> 
> Pn blocks give code sequences for CPU n
> 
> The 'exists' clause is evaluated after all Pn blocks are done.
> 
> There's others in this thread that can point you to many papers and
> resources on these litmus test thingies.
> 
> So basically the initial value of @v is set to 1.
> 
> Then CPU-1 does atomic_add_unless(v, 1, 0)
>      CPU-2 does atomic_set(v, 0)
> 
> If CPU1 goes first, it will see 1, which is not 0 and thus add 1 to 1
> and obtains 2. Then CPU2 goes and writes 0, so the exist clause sees
> v==0 and doesn't observe 2.
> 
> The other way around, CPU-2 goes first, writes a 0, then CPU-1 goes and
> observes the 0, finds it matches 0 and doesn't add.  Again, the exist
> clause will find 0 doesn't match 2.
> 
> This all goes unstuck if interleaved like:
> 
> 
> 	CPU-1			CPU-2
> 
> 				xor	t0, t0
> 1:	ll	t0, v
> 	bez	t0, 2f
> 				sw	t0, v
> 	add	t0, t1
> 	sc	t0, v
> 	beqz t0, 1b
> 
> (sorry if I got the MIPS asm wrong; it's not something I normally write)
> 
> And the store-word from CPU-2 doesn't make the SC from CPU-1 fail.
> 

loongson's llsc bug DOES NOT fail this litmus( we will not get V=2);

only speculative memory access from CPU-1 can "blind" CPU-1(here blind means do ll/sc
 wrong), this speculative memory access can be observed corrently by CPU2. In this 
case, sw from CPU-2 can get I , which can be observed by CPU-1, and clear llbit,then 
failed sc. 



北京市海淀区中关村环保科技示范园龙芯产业园2号楼 100095电话: +86 (10) 62546668传真: +86 (10) 62600826www.loongson.cn本邮件及其附件含有龙芯中科技术有限公司的商业秘密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部 分地泄露、复制或散发)本邮件及其附件中的信息。如果您错收本邮件,请您立即电话或邮件通知发件人并删除本邮件。 

This email and its attachments contain confidential information from Loongson
Technology Corporation Limited, which is intended only for the person or entity
whose address is listed above. Any use of the information contained herein in
any way (including, but not limited to, total or partial disclosure,
reproduction or dissemination) by persons other than the intended recipient(s)
is prohibited. If you receive this email in error, please notify the sender by
phone or email immediately and delete it. 

  reply	other threads:[~2019-04-25 12:51 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
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 [this message]
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=2ff11adc.c051.16a548cd90c.Coremail.huangpei@loongson.cn \
    --to=huangpei@loongson.cn \
    --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=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=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).