There is interest in mapping zeropages via vm_insert_pages() [1] into MAP_SHARED mappings. For now, we only get zeropages in MAP_SHARED mappings via vmf_insert_mixed() from FSDAX code, and I think it's a bit shaky in some cases because we refcount the zeropage when mapping it but not necessarily always when unmapping it ... and we should actually never refcount it. It's all a bit tricky, especially how zeropages in MAP_SHARED mappings interact with GUP (FOLL_LONGTERM), mprotect(), write-faults and s390x forbidding the shared zeropage (rewrite on its way upstream [2]). This series tries to take the careful approach of only allowing the zeropage where it is likely safe to use (which should cover the existing FSDAX use case and [1]), preventing that it could accidentially get mapped writable during a write fault, mprotect() etc, and preventing issues with FOLL_LONGTERM in the future with other users. Only very lightly tested ... because I yet have to even get fsdax running (I guess, file system on emulated DIMM in a VM? Hmmm :) ). [1] https://lkml.kernel.org/r/20240430111354.637356-1-vdonnefort@xxxxxxxxxx [2] https://lkml.kernel.org/r/20240411161441.910170-1-david@xxxxxxxxxx Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Cc: Vincent Donnefort <vdonnefort@xxxxxxxxxx> Cc: Dan Williams <dan.j.williams@xxxxxxxxx> David Hildenbrand (2): mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed() mm/rmap: sanity check that zeropages are not passed to RMAP include/linux/rmap.h | 3 ++ mm/memory.c | 92 ++++++++++++++++++++++++++++++++++---------- mm/mprotect.c | 2 + 3 files changed, 76 insertions(+), 21 deletions(-) -- 2.44.0
