Re: [PATCH 5/7] mm: Replace hpage_nr_pages with thp_nr_pages

[Matthew Wilcox <willy@infradead.org>]

On Mon, Jun 29, 2020 at 07:14:40PM +0100, Matthew Wilcox wrote:
> Thank you!  Clearly I wasn't thinking about this patch and just did a
> mindless search-and-replace!  I should evaluate the other places where
> I did this and see if any of them are wrong too.

add_page_to_lru_list() and friends -- safe.  hugetlbfs doesn't use the
  LRU lists.
find_subpage() -- safe.  hugetlbfs has already returned by this point.
readahead_page() and friends -- safe.  hugetlbfs doesn't readahead.
isolate_migratepages_block() -- probably safe.  I don't think hugetlbfs
  pages are migratable, and it calls del_page_from_lru_list(), so I
  infer hugetlbfs doesn't reach this point.
unaccount_page_cache_page() -- safe.  hugetlbfs has already returned by
  this point.
check_and_migrate_cma_pages() -- CMA pages aren't hugetlbfs pages.
mlock_migrate_page() -- not used for hugetlbfs.
mem_cgroup_move_account() mem_cgroup_charge() mem_cgroup_migrate()
mem_cgroup_swapout() mem_cgroup_try_charge_swap() -- I don't think
  memory cgroups control hugetlbfs pages.
do_migrate_range() -- explicitly not in the hugetlb arm of this if
  statement
migrate_page_add() -- Assumes LRU
putback_movable_pages() -- Also LRU
expected_page_refs() migrate_page_move_mapping() copy_huge_page()
unmap_and_move() add_page_for_migration() numamigrate_isolate_page()
  -- more page migration
mlock.c: This is all related to being on the LRU list
page_io.c: We don't swap out hugetlbfs pages
pfn_is_match() -- Already returned from this function for hugetlbfs pages
do_page_add_anon_rmap() page_add_new_anon_rmap() rmap_walk_anon()
  -- hugetlbfs pages aren't anon.
rmap_walk_file() -- This one I'm unsure about.  There's explicit
  support for hugetlbfs elsewhere in the file, and maybe this is never
  called for hugetlb pages.  Help?
swap.c, swap_state.c, swapfile.c: No swap for hugetlbfs pages.
vmscan.c: hugetlbfs pages not on the LRUs
workingset.c: hugetlbfs pages not on the LRUs

So I think you found the only bug of this type, although I'm a little
unsure about the rmap_walk_file().