On Fri, 8 May 2026 16:55:15 +0100 "Kiryl Shutsemau (Meta)" <[email protected]> wrote:
> Userfaultfd RWP will reuse the uffd-wp PTE bit to mark access-tracking > PTEs, alongside the write-protected ones it already marks. The bit's > meaning now depends on the VMA flag (WP or RWP), not on its name. > > Rename the kernel-internal names that describe the bit: > > - pte/pmd/huge_pte accessors (and swap variants) > - pgtable_supports_uffd() capability query > - SCAN_PTE_UFFD khugepaged enum > > The ftrace string emitted by mm_khugepaged_scan_pmd for this enum is > kept as "pte_uffd_wp" so existing trace-based tooling keeps matching. > > Pure mechanical rename -- no behavior change. > > Signed-off-by: Kiryl Shutsemau <[email protected]> > Assisted-by: Claude:claude-opus-4-6 > Reviewed-by: Mike Rapoport (Microsoft) <[email protected]> Reviewed-by: SeongJae Park <[email protected]> [...] > @@ -4934,10 +4934,10 @@ int copy_hugetlb_page_range(struct mm_struct *dst, > struct mm_struct *src, > softleaf = softleaf_from_pte(entry); > if (unlikely(softleaf_is_hwpoison(softleaf))) { > if (!userfaultfd_wp(dst_vma)) > - entry = huge_pte_clear_uffd_wp(entry); > + entry = huge_pte_clear_uffd(entry); > set_huge_pte_at(dst, addr, dst_pte, entry, sz); > } else if (unlikely(softleaf_is_migration(softleaf))) { > - bool uffd_wp = pte_swp_uffd_wp(entry); > + bool uffd_wp = pte_swp_uffd(entry); Just curious. Is the variable name intentionally kept to avoid unnecessary change? Thanks, SJ [...]
