All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stian Halseth <stian@itx.no>
To: davem@davemloft.net, Andreas Larsson <andreas@gaisler.com>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	glaubitz@physik.fu-berlin.de, Stian Halseth <stian@itx.no>
Subject: [PATCH 3/3] sparc64: decide the TSB huge-page window fixup before the bank switch
Date: Fri, 28 Aug 2026 14:37:07 +0200	[thread overview]
Message-ID: <20260828123707.1852437-4-stian@itx.no> (raw)
In-Reply-To: <20260828123707.1852437-1-stian@itx.no>

The huge-page path in the TSB miss handler has to route a fault taken
during a register window spill or fill away from hugetlb_setup(), since
a trap stack cannot be built at TL > 1.  That test is made after

	wrpr	%g5, PSTATE_AG | PSTATE_MG, %pstate

(SET_GL(1) on sun4v) has already switched the global register bank.
%g3, holding the fault code, and %g5, holding the PTE, live in the TLB
miss handler's globals and do not survive that switch, so the branch to
winfix_trampoline passes on whatever the new bank happens to contain: a
stale fault code and a garbage fault address.  The task is then killed
with SIGSEGV pointing at an address that was never mapped.

The path predates the fault code being passed at all; it was given one
when winfix_trampoline's %g4 requirement was fixed, and the register it
reads has been the wrong bank's since.

Make the decision before the switch and route to tsb_do_fault, which
re-reads both from the MMU after switching banks, rather than entering
winfix_trampoline with registers that no longer mean anything.

Fixes: 84bd6d8b9c0f ("sparc64: Fix corrupted thread fault code.")
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: https://github.com/sparclinux/issues/issues/87
Signed-off-by: Stian Halseth <stian@itx.no>
---
 arch/sparc/kernel/tsb.S | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/kernel/tsb.S b/arch/sparc/kernel/tsb.S
index eaed39ce8938..a70d5b124a80 100644
--- a/arch/sparc/kernel/tsb.S
+++ b/arch/sparc/kernel/tsb.S
@@ -144,6 +144,26 @@ tsb_miss_page_table_walk_sun4v_fastpath:
 	bne,pt		%xcc, 60f
 	 nop
 
+	/* If this fault came from a window spill or fill (TL > 1),
+	 * we cannot build a trap stack and call hugetlb_setup() from
+	 * here.  Route it through tsb_do_fault instead, so that
+	 * do_sparc64_fault() runs and its huge-TSB grow check
+	 * allocates the TSB before the access is replayed.
+	 *
+	 * This must be decided before the register bank switch below:
+	 * %g3 (the fault code) and %g5 (now the PTE) live in the TLB
+	 * miss handler's globals and do not survive it.  Consuming
+	 * them after the switch, as this path used to when it went to
+	 * winfix_trampoline directly, records a stale %g3 as the
+	 * fault code and a stale %g5 as the fault address, and the
+	 * task is then killed with a SIGSEGV at a garbage address.
+	 * tsb_do_fault re-fetches both from the MMU after switching.
+	 */
+	rdpr	%tl, %g7
+	cmp	%g7, 1
+	bgu,pn	%xcc, tsb_do_fault
+	 nop
+
 661:	rdpr		%pstate, %g5
 	wrpr		%g5, PSTATE_AG | PSTATE_MG, %pstate
 	.section	.sun4v_2insn_patch, "ax"
@@ -152,10 +172,6 @@ tsb_miss_page_table_walk_sun4v_fastpath:
 	nop
 	.previous
 
-	rdpr	%tl, %g7
-	cmp	%g7, 1
-	bne,pn	%xcc, winfix_trampoline
-	 mov	%g3, %g4
 	ba,pt	%xcc, etrap
 	 rd	%pc, %g7
 	call	hugetlb_setup
-- 
2.43.0


      parent reply	other threads:[~2026-08-28 12:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 12:37 [PATCH 0/3] sparc64: fix a window fill fixup lockup and two fault bugs Stian Halseth
2026-08-28 12:37 ` [PATCH 1/3] sparc64: restore %asi in user_rtt_fill_fixup_common Stian Halseth
2026-08-28 12:37 ` [PATCH 2/3] sparc64: use the fault address for si_addr on window fixup faults Stian Halseth
2026-08-28 12:37 ` Stian Halseth [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=20260828123707.1852437-4-stian@itx.no \
    --to=stian@itx.no \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.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 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.