[v1,0/6] fs/proc: move page_mapcount() to fs/proc/internal.h

Message

David Hildenbrand June 7, 2024, 12:23 p.m. UTC

With all other page_mapcount() users in the tree gone, move
page_mapcount() to fs/proc/internal.h, rename it and extend the
documentation to prevent future (ab)use.

... of course, I find some issues while working on that code that I sort
first ;)

We'll now only end up calling page_mapcount()
[now folio_precise_page_mapcount()] on pages mapped via present page table
entries. Except for /proc/kpagecount, that still does questionable things,
but we'll leave that legacy interface as is for now.

Did a quick sanity check. Likely we would want some better selfestest
for /proc/$/pagemap + smaps. I'll see if I can find some time to write
some more.

Cc: Andrew Morton <[e-mail]>
Cc: Jonathan Corbet <[e-mail]>

David Hildenbrand (6):
  fs/proc/task_mmu: indicate PM_FILE for PMD-mapped file THP
  fs/proc/task_mmu: don't indicate PM_MMAP_EXCLUSIVE without PM_PRESENT
  fs/proc/task_mmu: properly detect PM_MMAP_EXCLUSIVE per page of
    PMD-mapped THPs
  fs/proc/task_mmu: account non-present entries as "maybe shared, but no
    idea how often"
  fs/proc: move page_mapcount() to fs/proc/internal.h
  Documentation/admin-guide/mm/pagemap.rst: drop "Using pagemap to do
    something useful"

 Documentation/admin-guide/mm/pagemap.rst |  21 -----
 fs/proc/internal.h                       |  33 ++++++++
 fs/proc/page.c                           |  21 +++--
 fs/proc/task_mmu.c                       | 102 +++++++++++++----------
 include/linux/mm.h                       |  27 +-----
 5 files changed, 104 insertions(+), 100 deletions(-)


base-commit: 19b8422c5bd56fb5e7085995801c6543a98bda1f

Comments

Oscar Salvador June 7, 2024, 1:18 p.m. UTC | #1

On Fri, Jun 07, 2024 at 02:23:51PM +0200, David Hildenbrand wrote:
> With all other page_mapcount() users in the tree gone, move
> page_mapcount() to fs/proc/internal.h, rename it and extend the
> documentation to prevent future (ab)use.
> 
> ... of course, I find some issues while working on that code that I sort
> first ;)
> 
> We'll now only end up calling page_mapcount()
> [now folio_precise_page_mapcount()] on pages mapped via present page table
> entries. Except for /proc/kpagecount, that still does questionable things,
> but we'll leave that legacy interface as is for now.
> 
> Did a quick sanity check. Likely we would want some better selfestest
> for /proc/$/pagemap + smaps. I'll see if I can find some time to write
> some more.

I stumbled upon some of these issues while unifying .{pud/pmd}_entry and
.hugetlb_entry.
I am not sure what is the current state of pagemap/smaps selftest, but
since I am going to need them anyway to keep me in check and making sure
I do not break anything hugetlb-related, I might as well write some of
them.