From nobody Sat Sep 26 22:55:48 2026 Received: from mx.itxnorge.no (itx-kvm-14.itxnorge.no [91.189.121.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7EB63D646B; Fri, 28 Aug 2026 12:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.189.121.228 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920675; cv=none; b=hwrkbIpKbx1wz/s7Uzi+lqdxqKRBqi7uDSYuISVzCceXxSMobmc4oEHORi278FC4T08OLQmrDYe1WhtO8wpLT60aUwrK2AFEMZhZkRRwHniq3BPcNE98aJ1nVxLG5QReRc2/WXxapohwKoFFFw1fdM/CWHoxSdZ7Y6oJF6gKsSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920675; c=relaxed/simple; bh=oo6KV7zUyyEiWTF/mpP3ZgTJ52TgOt9ofBBLTeyNrNs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bYg8wSWBXAaz0jQMtSnecZD0gtVJNe55xlizx+ISe5gGxiPTrB85WU6OEGQfLEdPswyc0hjE99k8eKIptDzb21jU29dJwPj8zQdxHWmnyDsfAxoEfcszpliGlviNbupM39VFem9JjJE2h5vj+sJ20IUoTlSUCTN0kX1ygwqqzqY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no; spf=pass smtp.mailfrom=itx.no; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b=lXxyGBOZ; arc=none smtp.client-ip=91.189.121.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=itx.no Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b="lXxyGBOZ" From: Stian Halseth DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itx.no; s=mx.itx.no; t=1787920659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pxrgltKwht0j2/GB66AG5cKTYHSGd5M+OZGr77Ffeps=; b=lXxyGBOZsc9LbfVTjuxGvaK9k/v97BxkhiyTWetJNV8x6bddDhNyQIw6pYabQtho68TJF2 Q35siAt/0IcrsOqDfuy3hXOgoG4bmWeUgmFJPXidtDSmcqlevHzGgNqPWZUQzof6vuuksa EQlsAC/TWy6jXmpiv/y7XV0Z4jEpggs= To: davem@davemloft.net, Andreas Larsson Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, glaubitz@physik.fu-berlin.de, Stian Halseth Subject: [PATCH 1/3] sparc64: restore %asi in user_rtt_fill_fixup_common Date: Fri, 28 Aug 2026 14:37:05 +0200 Message-ID: <20260828123707.1852437-2-stian@itx.no> In-Reply-To: <20260828123707.1852437-1-stian@itx.no> References: <20260828123707.1852437-1-stian@itx.no> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A window fill that faults re-enters the kernel through user_rtt_fill_fixup_common(), which does not pass through etrap. rtrap has already set %asi to ASI_AIUP for the fill, and etrap is what would normally re-establish ASI_AIUS from the TSTATE it synthesizes, so the kernel carries on with %asi =3D ASI_AIUP while the primary context has just been restored to the kernel's. Every %asi-based user access made from there - put_user(), get_user() and everything built on them - then translates in the kernel context. User addresses below the VA hole fault forever, because nothing ever fills a context-zero translation for them, and the CPU is wedged in kernel mode: the task survives SIGKILL, sits in state R at 100% CPU, and takes the machine down once RCU stalls. Addresses above the hole fail more quietly, silently aliasing the kernel linear mapping. Restore the invariant before any user access is attempted. Fixes: 7cafc0b8bf13 ("sparc64: Fix return from trap window fill crashes.") Reported-by: John Paul Adrian Glaubitz Link: https://github.com/sparclinux/issues/issues/87 Signed-off-by: Stian Halseth --- arch/sparc/kernel/urtt_fill.S | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/arch/sparc/kernel/urtt_fill.S b/arch/sparc/kernel/urtt_fill.S index e4cee7be5cd0..5acd27b18b1e 100644 --- a/arch/sparc/kernel/urtt_fill.S +++ b/arch/sparc/kernel/urtt_fill.S @@ -1,4 +1,5 @@ /* SPDX-License-Identifier: GPL-2.0 */ +#include #include #include #include @@ -32,6 +33,20 @@ user_rtt_fill_fixup_common: sethi %hi(KERNBASE), %g1 flush %g1 =20 + /* rtrap set %asi to ASI_AIUP for the window fill, and + * we re-enter the kernel here without passing through + * etrap, which would have re-established ASI_AIUS via + * the TSTATE it synthesizes. The primary context was + * just restored to the kernel's above, so a leftover + * ASI_AIUP makes every %asi-based user access (put_user, + * get_user) translate in the kernel context: user + * addresses below the VA hole then fault forever + * (nothing ever fills a context-zero translation for + * them), and addresses above it silently alias the + * kernel linear mapping. Restore the kernel invariant. + */ + wr %g0, ASI_AIUS, %asi + mov %g4, %l4 mov %g5, %l5 brnz,pn %g3, 1f --=20 2.43.0 From nobody Sat Sep 26 22:55:48 2026 Received: from mx.itxnorge.no (itx-kvm-14.itxnorge.no [91.189.121.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 159283CFF61; Fri, 28 Aug 2026 12:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.189.121.228 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920668; cv=none; b=GbuvDV9anGkTKG8G3nMX4xtlfPAyZTB0p9g2veWmBxtdt/VbsKwdi0Nb/08oXM+q6eH8Yvit813qpsArBRfgmzDXDcR9i324Is4TdPgM2y+VyKMjozmWBQmsnsma2EjjF8CwcrTrug/h2N8PsaLPmms4YBECFrGEYt9NRyFcjqM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920668; c=relaxed/simple; bh=/TNDYjWRFTHxSjGVI7JxoVWwxY5soUI17LJH6Ud5Eek=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I1HcqMseVMDHFHKTUAY6AmsutRjQnHOCVct3DNi3V3q+MTae08qvoSm/UB3E+BmmXTfsnFif1Nfuax0SJmnKF/cYQKZ8ATmYPy8IPDfdf6Uj//bfOUBBXSGMc6/sXjfl6NVXrk7wzmAnIBPVctgvIgeTOoJP5+nty7domavVvo8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no; spf=pass smtp.mailfrom=itx.no; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b=mZpfusV7; arc=none smtp.client-ip=91.189.121.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=itx.no Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b="mZpfusV7" From: Stian Halseth DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itx.no; s=mx.itx.no; t=1787920659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FJQFyAYzT5dGvrkkw8+IS0Bzc2SUTqTRZYJ2UjPIrIw=; b=mZpfusV7fTbaVe4L6gugSwZW/NoBOdVM18XCDpdeDCmHG6NX7TR8fWkpOnTp8ZWLY1rv3x psKCV23XOG06nbioBmkAvWY0IxRzG8NwQm+nb71q60jRqpR1Tz/kL4XfIrZnMt8ATSpwJD sPJWL+ShnMMPtsZ1xJZx+++Yz0IiEWM= To: davem@davemloft.net, Andreas Larsson Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, glaubitz@physik.fu-berlin.de, Stian Halseth Subject: [PATCH 2/3] sparc64: use the fault address for si_addr on window fixup faults Date: Fri, 28 Aug 2026 14:37:06 +0200 Message-ID: <20260828123707.1852437-3-stian@itx.no> In-Reply-To: <20260828123707.1852437-1-stian@itx.no> References: <20260828123707.1852437-1-stian@itx.no> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" do_fault_siginfo() prefers an address decoded from the instruction at regs->tpc whenever one could be probed, falling back to the fault time address only when it could not. That premise does not hold for a fault taken during a register window spill or fill. There the instruction at regs->tpc is the one being resumed, not the access that faulted, so compute_effective_address() fabricates an address out of unrelated register contents. In one capture it decoded a branch and reported the value it found in %g5 as si_addr. Use the fault time address for FAULT_CODE_WINFIXUP. It may only have page granularity, but it is the address that actually faulted. Fixes: 70ffc6ebaead ("sparc64: Fix top-level fault handling bugs.") Link: https://github.com/sparclinux/issues/issues/87 Signed-off-by: Stian Halseth --- arch/sparc/mm/fault_64.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c index e326caf708c6..c37b24f757f4 100644 --- a/arch/sparc/mm/fault_64.c +++ b/arch/sparc/mm/fault_64.c @@ -165,6 +165,15 @@ static void do_fault_siginfo(int code, int sig, struct= pt_regs *regs, =20 if (fault_code & FAULT_CODE_ITLB) { addr =3D regs->tpc; + } else if (fault_code & FAULT_CODE_WINFIXUP) { + /* The fault came from a register window spill or fill, so + * the instruction at regs->tpc is the one being resumed, + * not the access that faulted. Decoding it would fabricate + * an address out of unrelated register contents; the fault + * time provided address is the real one, even if it only + * has page granularity. + */ + addr =3D fault_addr; } else { /* If we were able to probe the faulting instruction, use it * to compute a precise fault address. Otherwise use the fault --=20 2.43.0 From nobody Sat Sep 26 22:55:48 2026 Received: from mx.itxnorge.no (itx-kvm-14.itxnorge.no [91.189.121.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 446D944A701; Fri, 28 Aug 2026 12:37:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.189.121.228 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920673; cv=none; b=PChTb8iW4vosZzHwpm6J1dilJ5uzIBrfxMHAxluIe/DZV1Ou4T1A3ARsUfmBNKJVpLVxA5ifdPKPU8vmStaFP8VF5OnNTfyR5Nag2Mziijew7f6i/DYTmZvL+/cWJSAIHyE7sKySjt6Ccbjd0hEgNKGra/iQlxocYwjdaWOvSNc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787920673; c=relaxed/simple; bh=OmY+8PZlHKkkMXWeh0ben5lXrY6btWYfaFgkAQqKTMY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=atR6XPVwy0XyLYn6NvPlZ6Cpylhk5WnYOg6xVPxL4fwyJxqcv7GgWWmuTgMeoU97dw8q6BKQ09TeeOYV2LAahxxpIgWlYJ4os2kE0+gb2emL6MEaRbHvzVbhRnO+5vIm9ISirfW5yk2DVP6VSXtoLvnAutwbi1+4i3m5VyRvtAg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no; spf=pass smtp.mailfrom=itx.no; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b=Msat1m7/; arc=none smtp.client-ip=91.189.121.228 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=itx.no Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=itx.no Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=itx.no header.i=@itx.no header.b="Msat1m7/" From: Stian Halseth DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itx.no; s=mx.itx.no; t=1787920659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=f8O/Xp9V6094Ri0HZFEnYjkpNf8IyEr6Jqh1UvzCjF4=; b=Msat1m7/7vm1lPQRiZGUxDxwMs4lBbDDOeLPN8/+Vef7zKWc8WzTDqZhxFQCQ+ebSHsJYF LAjWJqBYhkr0hpq9f2wBpXdmB76ZLgVeClgGeEWvYMCW2xxTlwgm0eOCTjeu1ysculaszI 0NcEAGFX+j4i39RjszNz1EngoD5VO1U= To: davem@davemloft.net, Andreas Larsson Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, glaubitz@physik.fu-berlin.de, Stian Halseth 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 Message-ID: <20260828123707.1852437-4-stian@itx.no> In-Reply-To: <20260828123707.1852437-1-stian@itx.no> References: <20260828123707.1852437-1-stian@itx.no> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 Link: https://github.com/sparclinux/issues/issues/87 Signed-off-by: Stian Halseth --- 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 =20 + /* 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 =20 - rdpr %tl, %g7 - cmp %g7, 1 - bne,pn %xcc, winfix_trampoline - mov %g3, %g4 ba,pt %xcc, etrap rd %pc, %g7 call hugetlb_setup --=20 2.43.0