Re: [PATCH 06/10] mm/hugetlb: fix endless write fault on a leftover uffd bit
From: Lance Yang
Date: Sun Oct 18 2026 - 03:11:36 EST
On Thu, Oct 15, 2026 at 06:07:12PM +0200, David Hildenbrand (Arm) wrote:
>From: Josef Bacik <josef@xxxxxxxxxxxxxx>
>
>hugetlb_fault() resolves the uffd bit on a write fault only if the VMA is
>registered for userfaultfd write protection, and hugetlb_wp() bails out
>for any entry with the uffd bit set assuming hugetlb_fault() has already
>resolved it.
>
>When a read-only hugetlb entry with the uffd bit set is mapped in a VMA
>that is not registered for uffd-wp, a write fault to it never makes
>progress. If the access comes from the kernel, e.g. read(2) from
>/dev/zero into such page, the task spins in the page fault handler,
>ignores SIGKILL and keeps holding the locks taken by the system call.
>
>Such entries should not exist, but an unprivileged user can create them,
>for example with MADV_DONTNEED of a page protected with UFFDIO_RWPROTECT
>or with UFFDIO_COPY in MODE_WP racing with UFFDIO_UNREGISTER.
>
>Clear the uffd bit when the VMA is not registered for uffd-wp and let the
>fault proceed to hugetlb_wp(), like do_wp_page() does for regular pages.
>
>Note that a FOLL_FORCE write to a page protected with UFFDIO_RWPROTECT in
>a private VMA that was made PROT_NONE now drops the RWP protection of
>that page.
>
>Original fix generated by an LLM and sent in private by Josef.
>
>Fixes: 60d5b473d61b ("mm/hugetlb: fix uffd wr-protection for CoW optimization path")
>Reported-by: Chris Mason <mason@xxxxxxxxxx>
>Cc: stable@xxxxxxxxxxxxxxx
>Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
>[rppt: massage commit message]
>Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
>[ david: convert comment into a TODO ]
>Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
>---
LGTM!
Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>