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().
