From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794064175; b=blzsHpl66w4ORA7hEIkLZ3D2Sq5asZkep4jwB6AE5jkglVIAgZodFKDRIW7Q0xaZ5ywt FVfZnxOo4JIC3F1K4Mf7V7nSLswYAlSaCOvoSU88obNhp8+smJTvEC7PSAWKZ0J282pql koH53wxa375vUKHmxJXFonOj0dpPsoG29bT58IcQl3OwMha6rRkYkw5QG3Dn0BWHEv0Hh lB3CLSaBG7LB/vJ4et+nVAZ5Yzz8iBZlYaiybGup129vlEwFSb4D2TC/k2ag4vTdqDjK/ MQILEipQwP+oeK96FUnb7331ysFhE1VuYEsL8kiE1GHDFlUGtXZqIdE8eCv0BaNTTqg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794064175; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=GZEnM4d0z8KUv2SngU2CEPfwRFVft5yoJsbi7pjPjFk=; b=LXSf3xKSbJndW0zftPKyXvW7Sr0bBbAMtJ1Sdo7Q3KxDwhmowt/uLaAMws3y9kvmQTUr mbcuGGRiCFjyM/WyvAeMR5M+OHXnmeZWncigUEJ0tUx5MAYveBqxqdyTCdspMQmJocXLo 3dbyRlV3mTWNb58k2FAHFyEkBibV/OZwwDjsDtVeNYs0IA/OS5lBg9XH+j8BX25Sy+U+s Jb4ccp1E860xzGB+cRJnvFFiJPAyJhCczU5disXm2TrOtybZQXiKDRVDv/lcJIEfUUWxX MRTw47J+kWo2XsyiHcXM3cgetzxC1gQZdwOLycNOe5FrZVWLgqUrjxBFD9B1XhUydFA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=qtElDO6A; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C11C606A335; Sat, 7 Nov 2026 15:09:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=qtElDO6A Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BC351F0089F; Sat, 7 Nov 2026 15:09:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794064175; bh=GZEnM4d0z8KUv2SngU2CEPfwRFVft5yoJsbi7pjPjFk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=qtElDO6ApX+7fp6fLbAFvkRL/vz+Jkl6oVG/z94lK8WQSxj9nV8GwiZ/I4BfN22YN xjSAeEs1uRNjhwmCpb4Zj5iM3aM24y80nz1lmZtgblssnzaRVbq/C74gXLsSZ/1Pxc /wzyfWhLNQz884nouwDaKbKUGQ0UVddx9PNZhUE8= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Orgad Shaneh , Thomas Bogendoerfer , Sasha Levin Subject: [PATCH 7.3 0320/1257] MIPS: mm: do not write a huge TLB entry when the probe misses Date: Sat, 7 Nov 2026 08:43:36 -0500 Message-ID: <20261107134948.267155030@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261107134939.434104957@linuxfoundation.org> References: <20261107134939.434104957@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: patches@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.3-stable review patch. If anyone has any objections, please let me know. ------------------ From: Orgad Shaneh [ Upstream commit 0cb17268887e1df5c425ea052f5146b42d126323 ] __update_tlb() probes for the 8K pair at the address it is given and, for a huge pmd, writes the huge entry with tlbwi at the probed index or with tlbwr when the probe misses. That works only if the caller passes the faulting address, so that the probe finds the 4K entry the refill handler loaded for the faulting page and the huge entry replaces it. update_mmu_cache_pmd() is not called that way. do_set_pmd() has always passed the huge-aligned address, and since commit ebcfc63d6bca ("mm: abstract THP allocation") the anonymous THP fault path does too (map_anon_folio_pmd()). The probe then misses the stale 4K entry, which sits at the faulting page somewhere else in the 2 MB range, tlbwr adds a huge entry next to it, and the TLB holds two entries matching the faulting address. Octeon raises "Machine Check exception - caused by multiple matching entries in the TLB" on the next refill of that page; a process on a CN63XX board died this way within a second of start, on the first anonymous THP of its bss. Skip the write when the probe misses. The refill and TLBL/TLBS handlers probe the faulting address themselves and rewrite the stale entry with the huge one (they also set the software young bit), so the entry is installed on the next access at the cost of one exception. Fixes: fd062c847a8c ("MIPS: TLB support for hugetlbfs.") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: Orgad Shaneh Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin --- arch/mips/mm/tlb-r4k.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c index 24fe85fa169d1..78bafa317fa6f 100644 --- a/arch/mips/mm/tlb-r4k.c +++ b/arch/mips/mm/tlb-r4k.c @@ -332,6 +332,19 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) /* this could be a huge page */ if (pmd_leaf(*pmdp)) { unsigned long lo; + + /* + * The probe above only covers the 8K pair at @address, and + * a huge mapping is installed with the huge-aligned address + * while the refill that started the fault left a 4K entry + * for the faulting page elsewhere in the range. Writing the + * huge entry to a random index would leave two entries + * matching the faulting address; leave it to the refill and + * TLBL/TLBS handlers, which probe the faulting address. + */ + if (idx < 0) + goto out; + write_c0_pagemask(PM_HUGE_MASK); ptep = (pte_t *)pmdp; lo = pte_to_entrylo(pte_val(*ptep)); @@ -339,10 +352,7 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) write_c0_entrylo1(lo + (HPAGE_SIZE >> 7)); mtc0_tlbw_hazard(); - if (idx < 0) - tlb_write_random(); - else - tlb_write_indexed(); + tlb_write_indexed(); tlbw_use_hazard(); write_c0_pagemask(PM_DEFAULT_MASK); } else @@ -380,6 +390,9 @@ void __update_tlb(struct vm_area_struct * vma, unsigned long address, pte_t pte) tlb_write_indexed(); } tlbw_use_hazard(); +#ifdef CONFIG_MIPS_HUGE_TLB_SUPPORT +out: +#endif htw_start(); flush_micro_tlb_vm(vma); -- 2.53.0