summaryrefslogtreecommitdiff
path: root/arch/s390/include/asm/pgtable.h
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2024-04-11 19:14:40 +0300
committerAlexander Gordeev <agordeev@linux.ibm.com>2024-04-18 16:02:53 +0300
commit90a7592da14951bd21f74a53246ba30955a648aa (patch)
tree4850ece8e83a760dae239316138649bec8897d6e /arch/s390/include/asm/pgtable.h
parent39cd87c4eb2b893354f3b850f916353f2658ae6f (diff)
downloadlinux-90a7592da14951bd21f74a53246ba30955a648aa.tar.xz
mm/userfaultfd: Do not place zeropages when zeropages are disallowed
s390x must disable shared zeropages for processes running VMs, because the VMs could end up making use of "storage keys" or protected virtualization, which are incompatible with shared zeropages. Yet, with userfaultfd it is possible to insert shared zeropages into such processes. Let's fallback to simply allocating a fresh zeroed anonymous folio and insert that instead. mm_forbids_zeropage() was introduced in commit 593befa6ab74 ("mm: introduce mm_forbids_zeropage function"), briefly before userfaultfd went upstream. Note that we don't want to fail the UFFDIO_ZEROPAGE request like we do for hugetlb, it would be rather unexpected. Further, we also cannot really indicated "not supported" to user space ahead of time: it could be that the MM disallows zeropages after userfaultfd was already registered. [ agordeev: Fixed checkpatch complaints ] Fixes: c1a4de99fada ("userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation") Reviewed-by: Peter Xu <peterx@redhat.com> Link: https://lore.kernel.org/r/20240411161441.910170-2-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Diffstat (limited to 'arch/s390/include/asm/pgtable.h')
0 files changed, 0 insertions, 0 deletions