Patch "mm/userfaultfd: Do not place zeropages when zeropages are disallowed" has been added to the 6.8-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    mm/userfaultfd: Do not place zeropages when zeropages are disallowed

to the 6.8-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     mm-userfaultfd-do-not-place-zeropages-when-zeropages.patch
and it can be found in the queue-6.8 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 1a6e0bc5723868841619e86a37767c7d9f0c1938
Author: David Hildenbrand <david@xxxxxxxxxx>
Date:   Thu Apr 11 18:14:40 2024 +0200

    mm/userfaultfd: Do not place zeropages when zeropages are disallowed
    
    [ Upstream commit 90a7592da14951bd21f74a53246ba30955a648aa ]
    
    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@xxxxxxxxxx>
    Link: https://lore.kernel.org/r/20240411161441.910170-2-david@xxxxxxxxxx
    Signed-off-by: David Hildenbrand <david@xxxxxxxxxx>
    Signed-off-by: Alexander Gordeev <agordeev@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index 313f1c42768a6..aa8f5a6c324ee 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -213,6 +213,38 @@ static int mfill_atomic_pte_copy(pmd_t *dst_pmd,
 	goto out;
 }
 
+static int mfill_atomic_pte_zeroed_folio(pmd_t *dst_pmd,
+					 struct vm_area_struct *dst_vma,
+					 unsigned long dst_addr)
+{
+	struct folio *folio;
+	int ret = -ENOMEM;
+
+	folio = vma_alloc_zeroed_movable_folio(dst_vma, dst_addr);
+	if (!folio)
+		return ret;
+
+	if (mem_cgroup_charge(folio, dst_vma->vm_mm, GFP_KERNEL))
+		goto out_put;
+
+	/*
+	 * The memory barrier inside __folio_mark_uptodate makes sure that
+	 * zeroing out the folio become visible before mapping the page
+	 * using set_pte_at(). See do_anonymous_page().
+	 */
+	__folio_mark_uptodate(folio);
+
+	ret = mfill_atomic_install_pte(dst_pmd, dst_vma, dst_addr,
+				       &folio->page, true, 0);
+	if (ret)
+		goto out_put;
+
+	return 0;
+out_put:
+	folio_put(folio);
+	return ret;
+}
+
 static int mfill_atomic_pte_zeropage(pmd_t *dst_pmd,
 				     struct vm_area_struct *dst_vma,
 				     unsigned long dst_addr)
@@ -221,6 +253,9 @@ static int mfill_atomic_pte_zeropage(pmd_t *dst_pmd,
 	spinlock_t *ptl;
 	int ret;
 
+	if (mm_forbids_zeropage(dst_vma->vm_mm))
+		return mfill_atomic_pte_zeroed_folio(dst_pmd, dst_vma, dst_addr);
+
 	_dst_pte = pte_mkspecial(pfn_pte(my_zero_pfn(dst_addr),
 					 dst_vma->vm_page_prot));
 	ret = -EAGAIN;