From: Barry Song <v-songbaohua@xxxxxxxx> The whole thing was originally suggested by David while we tried to weaken the WARN_ON in __folio_add_anon_rmap() while bringing up mTHP swapin[1]. This patchset is also preparatory work for mTHP swapin. folio_add_new_anon_rmap() assumes that new anon rmaps are always exclusive. However, this assumption doesn’t hold true for cases like do_swap_page(), where a new anon might be added to the swapcache and is not necessarily exclusive. The patchset extends the rmap flags to allow folio_add_new_anon_rmap() to handle both exclusive and non-exclusive new anon folios. The do_swap_page() function is updated to use this extended API with rmap flags. Consequently, all new anon folios now consistently use folio_add_new_anon_rmap(). The special case for !folio_test_anon() in __folio_add_anon_rmap() can be safely removed. In conclusion, new anon folios always use folio_add_new_anon_rmap(), regardless of exclusivity. Old anon folios continue to use __folio_add_anon_rmap() via folio_add_anon_rmap_pmd() and folio_add_anon_rmap_ptes(). [1] https://lore.kernel.org/linux-mm/20240118111036.72641-6-21cnbao@xxxxxxxxx/ Barry Song (3): mm: extend rmap flags arguments for folio_add_new_anon_rmap mm: do_swap_page: use folio_add_new_anon_rmap() if folio_test_anon(folio)==false mm: remove folio_test_anon(folio)==false path in __folio_add_anon_rmap() include/linux/rmap.h | 2 +- kernel/events/uprobes.c | 2 +- mm/huge_memory.c | 2 +- mm/khugepaged.c | 2 +- mm/memory.c | 12 +++++++----- mm/migrate_device.c | 2 +- mm/rmap.c | 32 ++++++++++++-------------------- mm/swapfile.c | 2 +- mm/userfaultfd.c | 2 +- 9 files changed, 26 insertions(+), 32 deletions(-) -- 2.34.1
