From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Paul Burton <paul.burton@mips.com>
Cc: Huacai Chen <chenhc@lemote.com>,
Ralf Baechle <ralf@linux-mips.org>,
James Hogan <jhogan@kernel.org>,
linux-mips@linux-mips.org, Fuxin Zhang <zhangfx@lemote.com>,
Zhangjin Wu <wuzhangjin@gmail.com>,
Huacai Chen <chenhuacai@gmail.com>,
stable@vger.kernel.org, Alan Stern <stern@rowland.harvard.edu>,
Andrea Parri <andrea.parri@amarulasolutions.com>,
Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Akira Yokosawa <akiyks@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3
Date: Tue, 17 Jul 2018 11:03:12 -0700 [thread overview]
Message-ID: <20180717180312.GP12945@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180717175232.ea7pi2bqswnzmznc@pburton-laptop>
On Tue, Jul 17, 2018 at 10:52:32AM -0700, Paul Burton wrote:
> Hi Huacai,
>
> On Fri, Jul 13, 2018 at 03:37:57PM +0800, Huacai Chen wrote:
> > Linux expects that if a CPU modifies a memory location, then that
> > modification will eventually become visible to other CPUs in the system.
> >
> > On Loongson-3 processor with SFB (Store Fill Buffer), loads may be
> > prioritised over stores so it is possible for a store operation to be
> > postponed if a polling loop immediately follows it. If the variable
> > being polled indirectly depends on the outstanding store [for example,
> > another CPU may be polling the variable that is pending modification]
> > then there is the potential for deadlock if interrupts are disabled.
> > This deadlock occurs in qspinlock code.
> >
> > This patch changes the definition of cpu_relax() to smp_mb() for
> > Loongson-3, forcing a flushing of the SFB on SMP systems before the
> > next load takes place. If the Kernel is not compiled for SMP support,
> > this will expand to a barrier() as before.
> >
> > References: 534be1d5a2da940 (ARM: 6194/1: change definition of cpu_relax() for ARM11MPCore)
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Huacai Chen <chenhc@lemote.com>
> > ---
> > arch/mips/include/asm/processor.h | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/arch/mips/include/asm/processor.h b/arch/mips/include/asm/processor.h
> > index af34afb..a8c4a3a 100644
> > --- a/arch/mips/include/asm/processor.h
> > +++ b/arch/mips/include/asm/processor.h
> > @@ -386,7 +386,17 @@ unsigned long get_wchan(struct task_struct *p);
> > #define KSTK_ESP(tsk) (task_pt_regs(tsk)->regs[29])
> > #define KSTK_STATUS(tsk) (task_pt_regs(tsk)->cp0_status)
> >
> > +#ifdef CONFIG_CPU_LOONGSON3
> > +/*
> > + * Loongson-3's SFB (Store-Fill-Buffer) may get starved when stuck in a read
> > + * loop. Since spin loops of any kind should have a cpu_relax() in them, force
> > + * a Store-Fill-Buffer flush from cpu_relax() such that any pending writes will
> > + * become available as expected.
> > + */
>
> I think "may starve writes" or "may queue writes indefinitely" would be
> clearer than "may get starved".
>
> > +#define cpu_relax() smp_mb()
> > +#else
> > #define cpu_relax() barrier()
> > +#endif
> >
> > /*
> > * Return_address is a replacement for __builtin_return_address(count)
> > --
> > 2.7.0
>
> Apart from the comment above though this looks better to me.
>
> Re-copying the LKMM maintainers - are you happy(ish) with this?
This looks much better to me.
Thanx, Paul
next prev parent reply other threads:[~2018-07-17 18:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 7:37 [PATCH] MIPS: Change definition of cpu_relax() for Loongson-3 Huacai Chen
2018-07-17 17:52 ` Paul Burton
2018-07-17 18:03 ` Paul E. McKenney [this message]
2018-07-17 18:46 ` Peter Zijlstra
2018-07-18 1:15 ` Huacai Chen
2018-07-19 21:15 ` Paul Burton
2018-07-21 1:35 ` 陈华才
2018-07-23 17:37 ` Paul Burton
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=20180717180312.GP12945@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=chenhc@lemote.com \
--cc=chenhuacai@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=paul.burton@mips.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=stable@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
--cc=wuzhangjin@gmail.com \
--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.