[PATCH RFC 0/3] mm: clarify folio_add_new_anon_rmap() and __folio_add_anon_rmap()

From: Barry Song
Date: Wed Jun 12 2024 - 20:07:56 EST


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