linux-kernel - [PATCH RFC 0/3] mm: clarify folio_add_new_anon_rmap() and __folio_add_anon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20240613000721.23093-1-21cnbao@gmail.com>
Date: Thu, 13 Jun 2024 12:07:18 +1200
From: Barry Song <21cnbao@...il.com>
To: david@...hat.com,
	akpm@...ux-foundation.org,
	linux-mm@...ck.org
Cc: chrisl@...nel.org,
	linux-kernel@...r.kernel.org,
	mhocko@...e.com,
	ryan.roberts@....com,
	baolin.wang@...ux.alibaba.com,
	yosryahmed@...gle.com,
	shy828301@...il.com,
	surenb@...gle.com,
	v-songbaohua@...o.com,
	willy@...radead.org,
	ying.huang@...el.com,
	yuzhao@...gle.com
Subject: [PATCH RFC 0/3] mm: clarify folio_add_new_anon_rmap() and __folio_add_anon_rmap()

From: Barry Song <v-songbaohua@...o.com>

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@gmail.com/

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