From: Magnus Lindholm <linmag7@gmail.com>
To: davem@davemloft.net, andreas@gaisler.com
Cc: sam@ravnborg.org, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, linmag7@gmail.com
Subject: [PATCH v2 2/2] sparc32: synchronize SuperSPARC instruction updates
Date: Thu, 17 Sep 2026 09:57:05 +0200 [thread overview]
Message-ID: <20260917075842.784996-3-linmag7@gmail.com> (raw)
In-Reply-To: <20260917075842.784996-1-linmag7@gmail.com>
SuperSPARC keeps its instruction cache coherent by snooping bus
transactions, so no remote processor has to be told about modified
instructions. A FLUSH is still required on the processor that wrote them:
the store buffer is not snooped, so FLUSH is what pushes the new
instructions into the coherent hierarchy, and it clears that processor's
own pipeline and instruction buffer.
Two Viking paths performed no flush at all.
viking_flush_sig_insns() was an empty stub, so it provided no explicit
instruction-update synchronization after the kernel wrote a signal
trampoline. Implement it.
flush_icache_range() was defined as do { } while (0) on sparc32, so it
provided no explicit instruction-update synchronization after the module
loader or a kernel text-modification path wrote executable code. Implement
it for Viking.
Both operations remain local. Hardware snooping maintains instruction-cache
coherence on the other processors, so no remote FLUSH is needed for that
purpose. Retain the existing Viking bypass of the SMP sig_insns wrapper.
Safe execution during a text update is the caller's responsibility. For
example, the module loader calls flush_module_icache() before
complete_formation() and do_init_module(). KGDB normally requests a CPU
roundup before modifying text, but that mechanism has exceptions and a
timeout; it is not an unconditional guarantee that every other CPU is
parked. A later cross-call cannot prevent an old instruction from executing
before it arrives, and cannot by itself make an otherwise unsafe concurrent
text modification safe.
The manual is explicit that FLUSH is not scoped to the address given to it:
"No cached information is explicitly flushed by the instruction ... FLUSH
operations simply cause an exact synchronization of all pending activity"
(section 7.4). One FLUSH therefore covers however many words were written
before it, which is why the two-instruction trampoline needs only one.
This follows SuperSPARC Family User's Manual sections 7.4, Flush (IFLUSH),
and 10.2.5, Instruction Cache Consistency, and SuperSPARC II Addendum
section A.8.2, Store Buffer & Snoops.
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
---
arch/sparc/include/asm/cacheflush_32.h | 2 +-
arch/sparc/mm/srmmu.c | 10 ++++++++++
arch/sparc/mm/viking.S | 5 +++++
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/include/asm/cacheflush_32.h b/arch/sparc/include/asm/cacheflush_32.h
index 9fee0ccfccb8..4249663efacc 100644
--- a/arch/sparc/include/asm/cacheflush_32.h
+++ b/arch/sparc/include/asm/cacheflush_32.h
@@ -15,7 +15,7 @@
sparc32_cachetlb_ops->cache_range(vma, start, end)
#define flush_cache_page(vma,addr,pfn) \
sparc32_cachetlb_ops->cache_page(vma, addr)
-#define flush_icache_range(start, end) do { } while (0)
+void flush_icache_range(unsigned long start, unsigned long end);
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
do { \
diff --git a/arch/sparc/mm/srmmu.c b/arch/sparc/mm/srmmu.c
index ea0cc3683ad2..093c543b734e 100644
--- a/arch/sparc/mm/srmmu.c
+++ b/arch/sparc/mm/srmmu.c
@@ -1784,6 +1784,16 @@ static struct sparc32_cachetlb_ops smp_cachetlb_ops __ro_after_init = {
};
#endif
+void flush_icache_range(unsigned long start, unsigned long end)
+{
+ if (start >= end || poke_srmmu != poke_viking)
+ return;
+
+ /* One local FLUSH synchronizes all preceding instruction stores. */
+ __asm__ __volatile__("flush %0" : : "r" (start) : "memory");
+}
+EXPORT_SYMBOL(flush_icache_range);
+
/* Load up routines and constants for sun4m and sun4d mmu */
void __init load_mmu(void)
{
diff --git a/arch/sparc/mm/viking.S b/arch/sparc/mm/viking.S
index 8b4e251bbba2..92c80426bca6 100644
--- a/arch/sparc/mm/viking.S
+++ b/arch/sparc/mm/viking.S
@@ -201,7 +201,12 @@ viking_flush_tlb_page:
viking_flush_page_to_ram:
viking_flush_page_for_dma:
+ retl
+ nop
+
viking_flush_sig_insns:
+ /* FLUSH is not address scoped here, so one covers both words. */
+ flush %o1
retl
nop
--
2.43.0
prev parent reply other threads:[~2026-09-17 7:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 7:57 [PATCH v2 0/2] sparc32: SuperSPARC SMP synchronization fixes Magnus Lindholm
2026-09-17 7:57 ` [PATCH v2 1/2] sparc32: serialize SuperSPARC demap operations Magnus Lindholm
2026-09-17 7:57 ` Magnus Lindholm [this message]
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=20260917075842.784996-3-linmag7@gmail.com \
--to=linmag7@gmail.com \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@ravnborg.org \
--cc=sparclinux@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®