Re: [PATCH] arm64: hugetlb: Prevent write fault livelocks on stale TLB entries

[Catalin Marinas <catalin.marinas@arm.com>]

On Wed, Nov 11, 2026 at 10:04:19AM +0100, Oscar Salvador (SUSE) wrote:
> 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: <stable@vger.kernel.org>
> > Signed-off-by: Chris Down <chris@chrisdown.name>
> 
> 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.

I think you mean non-contiguous hugetlb here? cb1fa2e99955 switched
__ptep_set_access_flags() to local invalidation, used on the
non-contiguous hugetlb path. Contiguous hugetlb updates still broadcast
through get_clear_contig_flush().

Ordinary contpte mappings also switched to local invalidation but those
go through the generic fault handler and its fix_spurious_fault()
fallback. That fallback is what the hugetlb path was missing.

-- 
Catalin