From: Paul Burton <paul.burton@mips.com>
To: Huang Pei <huangpei@loongson.cn>
Cc: Ralf Baechle <ralf@linux-mips.org>,
"ambrosehua@gmail.com" <ambrosehua@gmail.com>,
Paul Burton <pburton@wavecomp.com>,
"Steven J . Hill" <Steven.Hill@cavium.com>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>,
Li Xuefeng <lixuefeng@loongson.cn>,
Xu Chenghua <xuchenghua@loongson.cn>,
Huacai Chen <chenhc@lemote.com>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>
Subject: Re: [PATCH] MIPS: Loongson: Introduce and use loongson_llsc_mb()
Date: Mon, 4 Feb 2019 21:17:38 +0000 [thread overview]
Message-ID: <MWHPR2201MB1277AC96754C6D4993A17DD5C16D0@MWHPR2201MB1277.namprd22.prod.outlook.com> (raw)
In-Reply-To: <1547539494-7870-1-git-send-email-huangpei@loongson.cn>
Hello,
Huang Pei wrote:
> From: Huacai Chen <chenhc@lemote.com>
>
> On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
> lld/scd is very weak ordering. We should add sync instructions "before
> each ll/lld" and "at the branch-target between ll/sc" to workaround.
> Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
> heavy load test with LTP).
>
> Below is the explaination of CPU designer:
>
> "For Loongson 3 family, when a memory access instruction (load, store,
> or prefetch)'s executing occurs between the execution of LL and SC, the
> success or failure of SC is not predictable. Although programmer would
> not insert memory access instructions between LL and SC, the memory
> instructions before LL in program-order, may dynamically executed
> between the execution of LL/SC, so a memory fence (SYNC) is needed
> before LL/LLD to avoid this situation.
>
> Since Loongson-3A R2 (3A2000), we have improved our hardware design to
> handle this case. But we later deduce a rarely circumstance that some
> speculatively executed memory instructions due to branch misprediction
> between LL/SC still fall into the above case, so a memory fence (SYNC)
> at branch-target (if its target is not between LL/SC) is needed for
> Loongson 3A1000, 3B1500, 3A2000 and 3A3000.
>
> Our processor is continually evolving and we aim to to remove all these
> workaround-SYNCs around LL/SC for new-come processor."
>
> Here is an example:
>
> Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
> this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
> time('sc' return 1), and the variable is only *added by 1*, sometimes,
> which is wrong and unacceptable(it should be added by 2).
>
> Why disable fix-loongson3-llsc in compiler?
> Because compiler fix will cause problems in kernel's __ex_table section.
>
> This patch fix all the cases in kernel, but:
>
> +. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
> of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
> the ll and branch-target coincidently such as atomic_sub_if_positive/
> cmpxchg/xchg, just like this one.
>
> +. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
> edac.h
>
> +. local_ops and cmpxchg_local should not be affected by this bug since
> only the owner can write.
>
> +. mips_atomic_set for syscall.c is deprecated and rarely used, just let
> it go
>
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
> Signed-off-by: Huang Pei <huangpei@loongson.cn>
Applied to mips-fixes.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
parent reply other threads:[~2019-02-04 21:18 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <1547539494-7870-1-git-send-email-huangpei@loongson.cn>]
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=MWHPR2201MB1277AC96754C6D4993A17DD5C16D0@MWHPR2201MB1277.namprd22.prod.outlook.com \
--to=paul.burton@mips.com \
--cc=Steven.Hill@cavium.com \
--cc=ambrosehua@gmail.com \
--cc=chenhc@lemote.com \
--cc=huangpei@loongson.cn \
--cc=linux-mips@linux-mips.org \
--cc=linux-mips@vger.kernel.org \
--cc=lixuefeng@loongson.cn \
--cc=pburton@wavecomp.com \
--cc=ralf@linux-mips.org \
--cc=wuzhangjin@gmail.com \
--cc=xuchenghua@loongson.cn \
--cc=zhangfx@lemote.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).