From: Magnus Lindholm <linmag7@gmail.com>
To: davem@davemloft.net, andreas@gaisler.com
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
linmag7@gmail.com, stable@vger.kernel.org
Subject: [PATCH 3/9] sparc32: do not flush a NULL address in flush_dcache_folio
Date: Sun, 8 Nov 2026 23:34:13 +0100 [thread overview]
Message-ID: <20261108223516.1125534-4-linmag7@gmail.com> (raw)
In-Reply-To: <20261108223516.1125534-1-linmag7@gmail.com>
sparc_flush_folio_to_ram() is sparc32's flush_dcache_folio() and takes the
address to flush from folio_address(). For a highmem folio that is NULL,
so it flushes virtual address 0, and 0 + PAGE_SIZE and so on for a multi-
page folio.
On HyperSPARC, hypersparc_flush_page_to_ram() probes with
ASI_M_FLUSH_PROBE, finds nothing mapped at 0 and returns, so nothing is
flushed at all.
Returning early would be wrong: flush_dcache_folio() is also the barrier
taken before reading a folio userspace may have dirtied, as in
filemap_read() when the folio is writably mapped. Fall back to the whole-
cache operation, which reaches user aliases at any colour and on SMP is
cross-called to every cpu.
Do that only when the folio is mapped by userspace; otherwise the only
other mapping is the kmap_local slot, which arch_kmap_local_pre_unmap()
writes back on teardown. Without that test block_write_end() makes every
buffered write discard 512 KB of VAC, which cost 106 s against 56 s on a
64 MB dd.
With the mapping live and a reader on another cpu, 150 of 150 reads
returned stale data before and 0 of 150 after, every first mismatch on a
32-byte boundary, the VAC line size.
The separate HyperSPARC mapped-folio fix completes the lowmem and PKMAP
colour handling. The highmem fallback can be expensive for GUP: each
mapped folio may require whole-cache maintenance on all CPUs.
Fixes: 665f64029454 ("sparc32: implement the new page table range API")
Cc: stable@vger.kernel.org
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
---
arch/sparc/mm/init_32.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/sparc/mm/init_32.c b/arch/sparc/mm/init_32.c
index 7b53ee9f061f..9cf0065fc2d4 100644
--- a/arch/sparc/mm/init_32.c
+++ b/arch/sparc/mm/init_32.c
@@ -131,6 +131,16 @@ void sparc_flush_folio_to_ram(struct folio *folio)
unsigned long vaddr = (unsigned long)folio_address(folio);
unsigned int i, nr = folio_nr_pages(folio);
+ /*
+ * No kernel address to aim at. Only a user alias can be incoherent
+ * here; the kmap the kernel used is flushed when it is unmapped.
+ */
+ if (!vaddr) {
+ if (folio_mapped(folio))
+ flush_cache_all();
+ return;
+ }
+
for (i = 0; i < nr; i++)
__flush_page_to_ram(vaddr + i * PAGE_SIZE);
}
--
2.43.0
next prev parent reply other threads:[~2026-11-08 22:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 22:34 [PATCH 0/9] sparc32: repair cache hooks, mappings and TLB tracking Magnus Lindholm
2026-11-08 22:34 ` [PATCH 1/9] sparc32: inspect every PROM CPU cache geometry Magnus Lindholm
2026-11-08 22:34 ` [PATCH 2/9] sparc32: flush the source user alias in copy_user_highpage() Magnus Lindholm
2026-11-08 23:02 ` sashiko-bot
2026-11-08 22:34 ` Magnus Lindholm [this message]
2026-11-08 22:34 ` [PATCH 4/9] sparc32: flush the cache when a kmap_local mapping is installed Magnus Lindholm
2026-11-08 22:34 ` [PATCH 5/9] sparc32: preset modified and referenced bits in kmap PTEs Magnus Lindholm
2026-11-08 22:34 ` [PATCH 6/9] sparc32: colour-align private file mappings Magnus Lindholm
2026-11-08 22:34 ` [PATCH 7/9] sparc32: implement flush_anon_page Magnus Lindholm
2026-11-08 22:34 ` [PATCH 8/9] sparc32: retain mm_cpumask across TLB shootdowns Magnus Lindholm
2026-11-08 22:34 ` [PATCH 9/9] sparc32: enroll and order CPUs before switching address spaces Magnus Lindholm
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=20261108223516.1125534-4-linmag7@gmail.com \
--to=linmag7@gmail.com \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sparclinux@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
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.