From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0F46A33D2D7; Sun, 1 Jun 2025 23:45:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748821559; cv=none; b=gc2BdU/6+f+Rli0LFa2Rhpdht9fbPmB07T8cTEEs+FrGBoQKUdNCF+aS2PDSdBD+8mXMxUfg/NvyDZg2l5IaZHJ1w1MDO1VEDDxd2ZBbYweLO312Fbl2exxTBCj1S3w+WiiCcYA3An4kikmAXpxgOYb2HkIU0r5t23t0e57uDRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748821559; c=relaxed/simple; bh=oRYfet5O5zVlMoCwv5gI1g0JwzzmCXCTMTQmrGdRK0c=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=XBpgnPgx9IEJJfFpHd7UMra5pPf3r/MFKYvRoL4JfCPa8XOOQqgoXKdVTqvXP+YJSvnyPVMQOKAW5a2/kvTe6ho47mIHt6AvPykkR7NbDyqA8Vv1AMVlc9+LrFjXEmy1/QNhxHVIYbFC35nLvzKnIHX5dbgbkw3jidmZQ0/HZ04= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I0U8B0YM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I0U8B0YM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B00CEC4CEE7; Sun, 1 Jun 2025 23:45:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1748821558; bh=oRYfet5O5zVlMoCwv5gI1g0JwzzmCXCTMTQmrGdRK0c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I0U8B0YMuhWagaz1ITNqxJWxiJ/M2sfSQPrnBj43YrNdqDvPz6LmKbkl8LO9spYs4 piMQMg1fsOdm5frwKeN4p+81TMV1MJDUIB8+AqAZhPnOGYdRXXJWQP33SjMGAYqkT/ 0j2Zy732pBsbhPzaG6x4pCTnJHBuTkoANI7H8jjxU/HjccqgZPwcl44ggMpZlefQ4I iQfeHVnBEJtwBZFikUAnmWXAq2ZFKmmOq2nTpZHEe4DosXk4TubeIojnnrCmE40089 YJz4TN86KIRvltCJDzpWTeyfVfE+iHp1t7ylmBJ4N8s6dhzkgA3mxDxt4C7HJhQ+Qa F7OwhBOpF8v2g== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Simon Schuster , Andreas Oetken , Dinh Nguyen , Sasha Levin , linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 5.4 17/22] nios2: force update_mmu_cache on spurious tlb-permission--related pagefaults Date: Sun, 1 Jun 2025 19:45:08 -0400 Message-Id: <20250601234515.3519309-17-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250601234515.3519309-1-sashal@kernel.org> References: <20250601234515.3519309-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 5.4.293 Content-Transfer-Encoding: 8bit From: Simon Schuster [ Upstream commit 2d8a3179ea035f9341b6a73e5ba4029fc67e983d ] NIOS2 uses a software-managed TLB for virtual address translation. To flush a cache line, the original mapping is replaced by one to physical address 0x0 with no permissions (rwx mapped to 0) set. This can lead to TLB-permission--related traps when such a nominally flushed entry is encountered as a mapping for an otherwise valid virtual address within a process (e.g. due to an MMU-PID-namespace rollover that previously flushed the complete TLB including entries of existing, running processes). The default ptep_set_access_flags implementation from mm/pgtable-generic.c only forces a TLB-update when the page-table entry has changed within the page table: /* * [...] We return whether the PTE actually changed, which in turn * instructs the caller to do things like update__mmu_cache. [...] */ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address, pte_t *ptep, pte_t entry, int dirty) { int changed = !pte_same(*ptep, entry); if (changed) { set_pte_at(vma->vm_mm, address, ptep, entry); flush_tlb_fix_spurious_fault(vma, address); } return changed; } However, no cross-referencing with the TLB-state occurs, so the flushing-induced pseudo entries that are responsible for the pagefault in the first place are never pre-empted from TLB on this code path. This commit fixes this behaviour by always requesting a TLB-update in this part of the pagefault handling, fixing spurious page-faults on the way. The handling is a straightforward port of the logic from the MIPS architecture via an arch-specific ptep_set_access_flags function ported from arch/mips/include/asm/pgtable.h. Signed-off-by: Simon Schuster Signed-off-by: Andreas Oetken Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin --- **YES** This commit should be backported to stable kernel trees for the following reasons: **1. Fixes a Real User-Affecting Bug:** The commit addresses infinite page fault loops that can occur when: - NIOS2's software-managed TLB encounters spurious permission-related page faults - TLB entries flushed to physical address 0x0 with no permissions persist due to MMU-PID-namespace rollovers - The generic `ptep_set_access_flags` implementation fails to flush these stale TLB entries because it only flushes when the PTE actually changes in the page table **2. Small, Contained Fix:** The code change is minimal and surgical: - Adds an arch-specific `ptep_set_access_flags` function in `arch/nios2/include/asm/pgtable.h:284-297` - Always returns `true` to force `update_mmu_cache` execution, ensuring TLB invalidation even when the PTE hasn't changed - Identical pattern to MIPS architecture (arch/mips/include/asm/pgtable.h), proven and stable **3. Architecture- Specific with No Side Effects:** - Only affects NIOS2 architecture (`arch/nios2/include/asm/pgtable.h`) - No cross-architecture dependencies or changes to core MM code - Uses existing `set_ptes()` and `update_mmu_cache` infrastructure **4. Consistent with Similar Backported Fixes:** - Similar commit #5 (xtensa: define update_mmu_tlb function) was marked **YES** for backport with `Cc: stable@vger.kernel.org # 5.12+` - Both fix TLB invalidation issues in software-managed TLB architectures - Both address spurious page fault scenarios **5. Meets Stable Tree Criteria:** - **Important bugfix**: Prevents infinite page fault loops - **Minimal risk**: Architecture- specific, follows proven MIPS pattern - **No architectural changes**: Uses existing MM infrastructure - **Confined to subsystem**: Limited to NIOS2 TLB management The fix directly addresses a critical reliability issue where users experience system hangs due to infinite page faults, making it an ideal candidate for stable backporting. arch/nios2/include/asm/pgtable.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/nios2/include/asm/pgtable.h b/arch/nios2/include/asm/pgtable.h index 99985d8b71664..506bbc7730879 100644 --- a/arch/nios2/include/asm/pgtable.h +++ b/arch/nios2/include/asm/pgtable.h @@ -297,4 +297,20 @@ extern void __init mmu_init(void); extern void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t *pte); +static inline int pte_same(pte_t pte_a, pte_t pte_b); + +#define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS +static inline int ptep_set_access_flags(struct vm_area_struct *vma, + unsigned long address, pte_t *ptep, + pte_t entry, int dirty) +{ + if (!pte_same(*ptep, entry)) + set_ptes(vma->vm_mm, address, ptep, entry, 1); + /* + * update_mmu_cache will unconditionally execute, handling both + * the case that the PTE changed and the spurious fault case. + */ + return true; +} + #endif /* _ASM_NIOS2_PGTABLE_H */ -- 2.39.5