From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: 陈华才 <chenhc@lemote.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
stable <stable@vger.kernel.org>, Huang Pei <huangpei@loongson.cn>,
Paul Burton <paul.burton@mips.com>,
Ralf Baechle <ralf@linux-mips.org>,
ambrosehua <ambrosehua@gmail.com>,
"Steven J . Hill" <Steven.Hill@cavium.com>,
linux-mips <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>,
Sasha Levin <sashal@kernel.org>
Subject: Re: Re:[PATCH 4.9 81/96] MIPS: Loongson: Introduce and use loongson_llsc_mb()
Date: Wed, 13 Mar 2019 13:58:02 -0700 [thread overview]
Message-ID: <20190313205802.GC5289@kroah.com> (raw)
In-Reply-To: <tencent_033D72440ADE105C78D24982@qq.com>
On Wed, Mar 13, 2019 at 09:17:15PM +0800, 陈华才 wrote:
> Hi, GREG,
>
> 4.9 need to modify spinlock.h, please wait my patch.
>
>
>
> ---原始邮件---
> 发件人:"Greg Kroah-Hartman"<gregkh@linuxfoundation.org>
> 发送时间:2019年3月13日(星期三) 凌晨1:10
> 收件人:"linux-kernel"<linux-kernel@vger.kernel.org>;
> 主题:[PATCH 4.9 81/96] MIPS: Loongson: Introduce and use loongson_llsc_mb()
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> [ Upstream commit e02e07e3127d8aec1f4bcdfb2fc52a2d99b4859e ]
>
> 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)'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 ''un by two cpus (in atomic_add) succeed at same
> time(''eturn 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'__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 'e'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>
> [paul.burton@mips.com:
> - Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
> a comment describing why it'there.
> - Make loongson_llsc_mb() a no-op when
> CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
> barrier.
> - Add a comment describing the bug & how loongson_llsc_mb() helps
> in asm/barrier.h.]
> Signed-off-by: Paul Burton <paul.burton@mips.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: ambrosehua@gmail.com
> Cc: Steven J . Hill <Steven.Hill@cavium.com>
> Cc: linux-mips@linux-mips.org
> Cc: Fuxin Zhang <zhangfx@lemote.com>
> Cc: Zhangjin Wu <wuzhangjin@gmail.com>
> Cc: Li Xuefeng <lixuefeng@loongson.cn>
> Cc: Xu Chenghua <xuchenghua@loongson.cn>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> arch/mips/Kconfig | 15 ++++++++++++++
> arch/mips/include/asm/atomic.h | 6 ++++++
> arch/mips/include/asm/barrier.h | 36 +++++++++++++++++++++++++++++++++
> arch/mips/include/asm/bitops.h | 5 +++++
> arch/mips/include/asm/futex.h | 3 +++
> arch/mips/include/asm/pgtable.h | 2 ++
> arch/mips/loongson64/Platform | 23 +++++++++++++++++++++
> arch/mips/mm/tlbex.c | 10 +++++++++
> 8 files changed, 100 insertions(+)
Ok, I will go drop this from all stable queues now, thanks!
greg k-h
parent reply other threads:[~2019-03-13 20:58 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <tencent_033D72440ADE105C78D24982@qq.com>]
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=20190313205802.GC5289@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=Steven.Hill@cavium.com \
--cc=ambrosehua@gmail.com \
--cc=chenhc@lemote.com \
--cc=huangpei@loongson.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=lixuefeng@loongson.cn \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.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 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.