[PATCH v1 0/2] mm/memory: cleanly support zeropage in vm_insert_page*(), vm_map_pages*() and vmf_insert_mixed()

[David Hildenbrand]

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