From: Matt Redfearn <matt.redfearn@mips.com>
To: Ralf Baechle <ralf@linux-mips.org>, James Hogan <jhogan@kernel.org>
Cc: <linux-mips@linux-mips.org>,
Matt Redfearn <matt.redfearn@mips.com>,
"James Hogan" <james.hogan@mips.com>,
"stable # v4 . 9+" <stable@vger.kernel.org>,
Huacai Chen <chenhc@lemote.com>, <linux-kernel@vger.kernel.org>,
Paul Burton <paul.burton@mips.com>
Subject: [PATCH 2/3] MIPS: Add barrier between dcache & icache flushes
Date: Thu, 21 Dec 2017 11:16:03 +0000 [thread overview]
Message-ID: <1513854965-3880-2-git-send-email-matt.redfearn@mips.com> (raw)
In-Reply-To: <1513854965-3880-1-git-send-email-matt.redfearn@mips.com>
Index-based cache operations may be arbitrarily reordered by out of
order CPUs. Thus code which writes back the dcache & then invalidates
the icache using indexed cache ops must include a barrier between
operating on the 2 caches in order to prevent the scenario in which:
- icache invalidation occurs.
- icache fetch occurs, due to speculation.
- dcache writeback occurs.
If the above were allowed to happen then the icache would contain stale
data. Forcing the dcache writeback to complete before the icache
invalidation avoids this.
Similarly, the MIPS CM version 2 and above serialises D->I hit-based
cache operations to the same address, but older CMs and systems without
a MIPS CM do not and require the same barrier to ensure ordering.
To ensure these conditions, always enforce a barrier between D and I
cache operations.
Suggested-by: Leonid Yegoshin <Leonid.Yegoshin@mips.com>
Suggested-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Matt Redfearn <matt.redfearn@mips.com>
Cc: James Hogan <james.hogan@mips.com>
Cc: stable <stable@vger.kernel.org> # v4.9+
---
arch/mips/mm/c-r4k.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index ce7a54223504..b7186d47184b 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -741,6 +741,9 @@ static inline void __local_r4k_flush_icache_range(unsigned long start,
else
blast_dcache_range(start, end);
}
+
+ /* Ensure dcache operation has completed */
+ mb();
}
if (type == R4K_INDEX ||
--
2.7.4
next prev parent reply other threads:[~2017-12-21 11:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 11:16 [PATCH 1/3] MIPS: c-r4k: instruction_hazard should immediately follow cache op Matt Redfearn
2017-12-21 11:16 ` Matt Redfearn [this message]
2017-12-21 14:58 ` [PATCH 2/3] MIPS: Add barrier between dcache & icache flushes James Hogan
2017-12-21 11:16 ` [PATCH 3/3] MIPS: Add barrier between icache flush and execution hazard barrier Matt Redfearn
2017-12-21 15:14 ` [PATCH 1/3] MIPS: c-r4k: instruction_hazard should immediately follow cache op James Hogan
2017-12-21 15:19 ` Matt Redfearn
2017-12-21 15:30 ` James Hogan
2017-12-21 16:59 ` Matt Redfearn
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=1513854965-3880-2-git-send-email-matt.redfearn@mips.com \
--to=matt.redfearn@mips.com \
--cc=chenhc@lemote.com \
--cc=james.hogan@mips.com \
--cc=jhogan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@mips.com \
--cc=ralf@linux-mips.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
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
all inboxes | Powered by JetHome®