From: Ralf Baechle <ralf@linux-mips.org>
To: Chris Dearman <chris@mips.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Avoid potential hazard on Context register
Date: Mon, 12 Oct 2009 05:20:59 +0200 [thread overview]
Message-ID: <20091012032059.GA27744@linux-mips.org> (raw)
In-Reply-To: <4AD23F92.8030902@mips.com>
On Sun, Oct 11, 2009 at 01:26:58PM -0700, Chris Dearman wrote:
> Ralf Baechle wrote:
>> There is no hazard barrier between writes to c0_context and subsequent
>> read accesses. This is a fairly theoretical hole as c0_context is only
>> written on CPU bootup and other, unrelated code will almost certainly
> It was actually in the bootup code where I saw the problem, and this
> patch doesn't deal with that case:
>
>> MTC0 zero, CP0_CONTEXT # clear context
>> register PTR_LA $28, init_thread_union /* Set
>> the SP after an empty pt_regs. */ PTR_LI sp,
>> _THREAD_SIZE - 32 - PT_SIZE PTR_ADDU sp, $28
>> back_to_back_c0_hazard set_saved_sp sp, t0, t1
>
> The problem I observed is that the Context valuse used by set_saved_sp
> is whatever it inherits from YAMON.
So we need a double hazard barrier like below.
Ralf
There is no hazard barrier between writes to c0_context and subsequent
read accesses. This is a fairly theoretical hole as c0_context is only
written on CPU bootup and other, unrelated code will almost certainly
execute a hazard barrier somewhen between the write and read access.
Even if not, the window is probably in the thousands of cycles so likely
too large to actually consistute a pipeline hazard.
Reported and initial patch by Chris Dearman <chris@mips.com>.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
arch/mips/include/asm/mmu_context.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/include/asm/mmu_context.h b/arch/mips/include/asm/mmu_context.h
index ed331c2..d339d9d 100644
--- a/arch/mips/include/asm/mmu_context.h
+++ b/arch/mips/include/asm/mmu_context.h
@@ -16,6 +16,7 @@
#include <linux/smp.h>
#include <linux/slab.h>
#include <asm/cacheflush.h>
+#include <asm/hazards.h>
#include <asm/tlbflush.h>
#ifdef CONFIG_MIPS_MT_SMTC
#include <asm/mipsmtregs.h>
@@ -35,12 +36,16 @@ extern unsigned long pgd_current[];
#ifdef CONFIG_32BIT
#define TLBMISS_HANDLER_SETUP() \
+ back_to_back_c0_hazard(); \
write_c0_context((unsigned long) smp_processor_id() << 25); \
+ back_to_back_c0_hazard(); \
TLBMISS_HANDLER_SETUP_PGD(swapper_pg_dir)
#endif
#ifdef CONFIG_64BIT
#define TLBMISS_HANDLER_SETUP() \
+ back_to_back_c0_hazard(); \
write_c0_context((unsigned long) smp_processor_id() << 26); \
+ back_to_back_c0_hazard(); \
TLBMISS_HANDLER_SETUP_PGD(swapper_pg_dir)
#endif
next prev parent reply other threads:[~2009-10-12 3:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-11 6:07 [PATCH] Avoid potential hazard on Context register Chris Dearman
2009-10-11 13:39 ` Ralf Baechle
2009-10-11 14:53 ` Ralf Baechle
2009-10-11 20:26 ` Chris Dearman
2009-10-12 3:20 ` Ralf Baechle [this message]
2009-10-11 20:05 ` Chris Dearman
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=20091012032059.GA27744@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=chris@mips.com \
--cc=linux-mips@linux-mips.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 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.