Stable Archive on lore.kernel.org
 help / color / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: stable@vger.kernel.org, linux-mips@vger.kernel.org, chenhc@lemote.com
Subject: Re: [PATCH stable] MIPS: Loongson: Introduce and use loongson_llsc_mb()
Date: Sat, 1 Aug 2020 12:26:46 +0200
Message-ID: <20200801102646.GA3046974@kroah.com> (raw)
In-Reply-To: <20200801063443.1438289-1-jiaxun.yang@flygoat.com>

On Sat, Aug 01, 2020 at 02:34:43PM +0800, Jiaxun Yang wrote:
> From: Huacai Chen <chenhc@lemote.com>
> 
> commit e02e07e3127d8aec1f4bcdfb2fc52a2d99b4859e upstream.
> 
> 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>
> [paul.burton@mips.com:
>   - Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
>     a comment describing why it's 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>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.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>
> Cc: stable@vger.kernel.org # 4.19
> 
> ---
> Backport to stable according to request from Debian downstream.

What do you mean by "request"?

This feels like a new feature, why can't people just use the 5.4 kernel
or newer?  Given that this issue has been fixed upstream for 1 1/2
years, why does it need to go to the 4.19.y stable kernel now?

thanks,

greg k-h

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-01  6:34 Jiaxun Yang
2020-08-01 10:26 ` Greg KH [this message]
2020-08-01 11:48   ` Jiaxun Yang
2020-08-01 12:04     ` Greg KH
2020-08-01 14:11       ` Jiaxun Yang
2020-08-01 14:33         ` Greg KH

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=20200801102646.GA3046974@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=chenhc@lemote.com \
    --cc=jiaxun.yang@flygoat.com \
    --cc=linux-mips@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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

Stable Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ https://lore.kernel.org/stable \
		stable@vger.kernel.org
	public-inbox-index stable

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.stable


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git