mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2026-09-17 09:41:09 +02:00
mm/pagemap: add PAGE_IS_ACCESSED for RWP tracking
PAGEMAP_SCAN already reports PAGE_IS_WRITTEN from the inverted uffd PTE bit, targeting the UFFDIO_WRITEPROTECT workflow. UFFDIO_RWPROTECT reuses the same PTE bit as a marker for read-write protection, but "has been written" and "has been accessed" are distinct semantic signals — they happen to share one PTE bit today only because the two implementations share infrastructure. Give RWP its own pagemap category so the UAPI does not conflate them: PAGE_IS_WRITTEN reported on VM_UFFD_WP VMAs, !pte_uffd(pte) PAGE_IS_ACCESSED reported on VM_UFFD_RWP VMAs, !pte_uffd(pte) Both still read the same PTE bit today, but each is scoped to the VMA whose registered mode makes the bit meaningful. If a future implementation moves RWP to a separate PTE bit, only PAGE_IS_ACCESSED switches over. This is a UAPI narrowing. Outside VM_UFFD_WP VMAs the uffd bit is always clear, so PAGEMAP_SCAN used to flag PAGE_IS_WRITTEN on every present PTE there — a meaningless duplicate of PAGE_IS_PRESENT. Now PAGE_IS_WRITTEN fires only inside VM_UFFD_WP VMAs. pagemap_hugetlb_category() now takes the vma like its PTE/PMD peers. Link: https://lore.kernel.org/20260708111417.173443-12-kirill@shutemov.name Signed-off-by: Kiryl Shutsemau <kas@kernel.org> Assisted-by: Claude:claude-opus-4-6 Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: David Hildenbrand <david@kernel.org> Cc: James Houghton <jthoughton@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Liam Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: Sean Christopherson <seanjc@google.com> Cc: SeongJae Park <sj@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This commit is contained in:
committed by
Andrew Morton
parent
2d427bb016
commit
3389648819
@@ -19,8 +19,11 @@ There are four components to pagemap:
|
||||
* Bit 55 pte is soft-dirty (see
|
||||
Documentation/admin-guide/mm/soft-dirty.rst)
|
||||
* Bit 56 page exclusively mapped (since 4.2)
|
||||
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
|
||||
Documentation/admin-guide/mm/userfaultfd.rst)
|
||||
* Bit 57 pte is tracked by userfaultfd (since 5.13) — in a
|
||||
``VM_UFFD_WP`` VMA this indicates a write-protected PTE; in a
|
||||
``VM_UFFD_RWP`` VMA it indicates an RWP-protected PTE. WP and
|
||||
RWP are mutually exclusive per VMA, so the meaning is
|
||||
unambiguous. See Documentation/admin-guide/mm/userfaultfd.rst.
|
||||
* Bit 58 pte is a guard region (since 6.15) (see madvise (2) man page)
|
||||
* Bits 59-60 zero
|
||||
* Bit 61 page is file-page or shared-anon (since 3.5)
|
||||
@@ -244,7 +247,8 @@ in this IOCTL:
|
||||
Following flags about pages are currently supported:
|
||||
|
||||
- ``PAGE_IS_WPALLOWED`` - Page has async-write-protection enabled
|
||||
- ``PAGE_IS_WRITTEN`` - Page has been written to from the time it was write protected
|
||||
- ``PAGE_IS_WRITTEN`` - Page in a ``UFFDIO_REGISTER_MODE_WP`` VMA has been
|
||||
written to since it was write-protected. Only reported inside such VMAs.
|
||||
- ``PAGE_IS_FILE`` - Page is file backed
|
||||
- ``PAGE_IS_PRESENT`` - Page is present in the memory
|
||||
- ``PAGE_IS_SWAPPED`` - Page is in swapped
|
||||
@@ -252,6 +256,9 @@ Following flags about pages are currently supported:
|
||||
- ``PAGE_IS_HUGE`` - Page is PMD-mapped THP or Hugetlb backed
|
||||
- ``PAGE_IS_SOFT_DIRTY`` - Page is soft-dirty
|
||||
- ``PAGE_IS_GUARD`` - Page is a part of a guard region
|
||||
- ``PAGE_IS_ACCESSED`` - Page in a ``UFFDIO_REGISTER_MODE_RWP`` VMA has been
|
||||
accessed since RWP was applied. Only reported inside such VMAs. See
|
||||
Documentation/admin-guide/mm/userfaultfd.rst for the RWP workflow.
|
||||
|
||||
The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user