From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D2F360A2603 for ; Wed, 11 Nov 2026 09:04:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=LSAiIZQ7; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=HIi63Rsc DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=Uu+9KGMrpHo8NgeySjI/tnMOPCgQH/37jz3abKrEz2o=; b=LSAiIZQ7DCoVct5uABx2MLBxfG FlcMi13qSpe/v+c0WjxRhMBQg9SHwiUvK/6Gv1YFImUhYLdY9XX8oOhKxTBDW7cn4ecGP90evpV1z jyGAZiBwL2DarxafdsTlNk4aG81Lw0Tj7J62SYZNeZV0UowOuea8zgRSOs2mOaxDnigvOA9w7fUWt /OIl2pjvDMZjLlakZUb5uZgQO8Rl442n77gArhr9JZqUan+Dhg4UGCT8TYazuNQkrRSdIJMxbChhM 1ppH0nI4dPURffuvFZlBkYtbUGwUNw5jS0S6Wz0NBdOBJ8fxx7ff1vbnd3StoA0ypvGVY5LLCAf9I X9mZ9JaA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR4Fn-000000067Yk-4AAa; Wed, 11 Nov 2026 09:04:27 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR4Fm-000000067Ye-2c1e for linux-arm-kernel@lists.infradead.org; Wed, 11 Nov 2026 09:04:26 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id D4E7763BB0; Wed, 11 Nov 2026 09:04:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53ADA1F00A05; Wed, 11 Nov 2026 09:04:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794387865; bh=Uu+9KGMrpHo8NgeySjI/tnMOPCgQH/37jz3abKrEz2o=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HIi63Rsc072fcV3Tl1WAPHmCUz8w3a5jTfXsiegMUGVvyuq0PblXB+u68/3bRBoJO T1P0Y3HXdzA2glvFOEAULVTxX+f30mY5CzVeX37aHt4sn3Yq80qpmSNWLSpwA+QF5L +OWMh0pe3Wf/fuBagRsb2AAxmPmnH8HLa430rxxnafK5LaZUUdRqGILc0uzwMDQoS7 APpykF1PkmpRzUSEJIa6FImTQdljxta8iwjlHX+H7UxhNeqBY85ZZHGXyejxM+DtJm iFt4yxKv7HQ9sSl7td/sWSWxe9ov/nIWJbuwpsmeuFh2WB5KaNQWfbiChgOXpq5Q0q 4mRWIekkXy4BA== Date: Wed, 11 Nov 2026 10:04:19 +0100 From: "Oscar Salvador (SUSE)" To: Chris Down Cc: Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org, kernel-team@meta.com, Mark Rutland , Huang Ying , Andrew Morton , Muchun Song , Oscar Salvador , David Hildenbrand , Mike Kravetz , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH] arm64: hugetlb: Prevent write fault livelocks on stale TLB entries Message-ID: References: X-Archived-By: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-15.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Tue, Nov 10, 2026 at 08:39:02PM -0800, Chris Down wrote: > In Meta production, we have had tasks get stuck in a fault loop while > using hugetlb on arm64. During my investigations I found that affected > tasks share a private hugetlb page. > > Looking at the stuck task states, I found the following ordering: > > CPU0 CPU1 > ---- ---- > read page > [read only entry cached in TLB] > write page > hugetlb_fault() > hugetlb_wp() > [reuse folio] > set_huge_ptep_maybe_writable() > set_huge_ptep_writable() > [flush local TLB only] > > write page using stale entry > hugetlb_fault() > huge_ptep_set_access_flags() > [entry already writable, no flush] > retry write using stale entry > [fault indefinitely. well, that's not ideal!] > > The reason is that when a write fault makes a non-contiguous hugetlb > entry writable, it only invalidates the local TLB. However, another CPU > can keep the old read-only entry, so its write will fault even though > the page table already permits it. hugetlb_fault() then finds nothing to > change and leaves the stale entry in place, so the same write keeps > going round in circles. > > This is particularly bad because, if the kernel is copying to user > memory, the retry stays inside the kernel and the task can't act on the > pending signal. > > It can even remain unkillable while holding locks across the copy, > resulting in further failures. For example, a read into a hugetlb > buffer can hold the pipe mutex and block other users of the pipe until > the loop ends, causing cascading lockups across the machine. > > To fix this, when a write fault finds nothing to change in a > non-contiguous hugetlb entry, let's invalidate the local entry. > > Fixes: cb1fa2e99955 ("arm64, tlbflush: don't TLBI broadcast if page reused in write fault") > Cc: > Signed-off-by: Chris Down This makes sense to me, and I see that commit cb1fa2e99955 ("arm64, tlbflush: don't TLBI broadcast if page reused in write fault") only invalidated local tlb for cont-hugetlb. Reading the changelog, I guess that was an oversight because I could not find the reason behind. > --- > arch/arm64/mm/hugetlbpage.c | 21 ++++++++++++++++++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c > index 8e799c1fe0aa..ff1f53e435e1 100644 > --- a/arch/arm64/mm/hugetlbpage.c > +++ b/arch/arm64/mm/hugetlbpage.c > @@ -429,9 +429,24 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma, > VM_WARN_ON(!pte_present(pte)); > ncontig = num_contig_ptes(huge_page_size(hstate_vma(vma)), &pgsize); > > - if (!pte_cont(pte)) > - return __ptep_set_access_flags_anysz(vma, addr, ptep, pte, > - dirty, pgsize); > + if (!pte_cont(pte)) { > + if (__ptep_set_access_flags_anysz(vma, addr, ptep, pte, > + dirty, pgsize)) > + return 1; > + > + /* > + * Another CPU may have made the entry writable without > + * invalidating our stale read-only TLB entry. To avoid > + * indefinitely faulting on this entry, flush it. > + */ Maybe put that we already do that for cont-pte? -- Oscar Salvador SUSE Labs