From: Mike Kravetz <mike.kravetz@oracle.com>
To: "Axel Rasmussen" <axelrasmussen@google.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Alexey Dobriyan" <adobriyan@gmail.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Anshuman Khandual" <anshuman.khandual@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Chinwen Chang" <chinwen.chang@mediatek.com>,
"Huang Ying" <ying.huang@intel.com>,
"Ingo Molnar" <mingo@redhat.com>, "Jann Horn" <jannh@google.com>,
"Jerome Glisse" <jglisse@redhat.com>,
"Lokesh Gidra" <lokeshgidra@google.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Michal Koutný" <mkoutny@suse.com>,
"Michel Lespinasse" <walken@google.com>,
"Mike Rapoport" <rppt@linux.vnet.ibm.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Peter Xu" <peterx@redhat.com>, "Shaohua Li" <shli@fb.com>,
"Shawn Anastasio" <shawn@anastas.io>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Steven Price" <steven.price@arm.com>,
"Vlastimil Babka" <vbabka@suse.cz>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Adam Ruprecht <ruprecht@google.com>,
Cannon Matthews <cannonmatthews@google.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
David Rientjes <rientjes@google.com>,
Mina Almasry <almasrymina@google.com>,
Oliver Upton <oupton@google.com>
Subject: Re: [PATCH v5 04/10] hugetlb/userfaultfd: Unshare all pmds for hugetlbfs when register wp
Date: Fri, 12 Feb 2021 10:11:39 -0800 [thread overview]
Message-ID: <517f3477-cb80-6dc9-bda0-b147dea68f95@oracle.com> (raw)
In-Reply-To: <20210210212200.1097784-5-axelrasmussen@google.com>
On 2/10/21 1:21 PM, Axel Rasmussen wrote:
> From: Peter Xu <peterx@redhat.com>
>
> Huge pmd sharing for hugetlbfs is racy with userfaultfd-wp because
> userfaultfd-wp is always based on pgtable entries, so they cannot be shared.
>
> Walk the hugetlb range and unshare all such mappings if there is, right before
> UFFDIO_REGISTER will succeed and return to userspace.
>
> This will pair with want_pmd_share() in hugetlb code so that huge pmd sharing
> is completely disabled for userfaultfd-wp registered range.
>
> Signed-off-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
> ---
> fs/userfaultfd.c | 48 ++++++++++++++++++++++++++++++++++++
> include/linux/mmu_notifier.h | 1 +
> 2 files changed, 49 insertions(+)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index 0be8cdd4425a..1f4a34b1a1e7 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -15,6 +15,7 @@
> #include <linux/sched/signal.h>
> #include <linux/sched/mm.h>
> #include <linux/mm.h>
> +#include <linux/mmu_notifier.h>
> #include <linux/poll.h>
> #include <linux/slab.h>
> #include <linux/seq_file.h>
> @@ -1191,6 +1192,50 @@ static ssize_t userfaultfd_read(struct file *file, char __user *buf,
> }
> }
>
> +/*
> + * This function will unconditionally remove all the shared pmd pgtable entries
> + * within the specific vma for a hugetlbfs memory range.
> + */
> +static void hugetlb_unshare_all_pmds(struct vm_area_struct *vma)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> + struct hstate *h = hstate_vma(vma);
> + unsigned long sz = huge_page_size(h);
> + struct mm_struct *mm = vma->vm_mm;
> + struct mmu_notifier_range range;
> + unsigned long address;
> + spinlock_t *ptl;
> + pte_t *ptep;
> +
> + if (!(vma->vm_flags & VM_MAYSHARE))
> + return;
> +
> + /*
> + * No need to call adjust_range_if_pmd_sharing_possible(), because
> + * we're going to operate on the whole vma
> + */
This code will certainly work as intended. However, I wonder if we should
try to optimize and only flush and call huge_pmd_unshare for addresses where
sharing is possible. Consider this worst case example:
vm_start = 8G + 2M
vm_end = 11G - 2M
The vma is 'almost' 3G in size, yet only the range 9G to 10G is possibly
shared. This routine will potentially call lock/unlock ptl and call
huge_pmd_share for every huge page in the range. Ideally, we should only
make one call to huge_pmd_share with address 9G. If the unshare is
successful or not, we are done. The subtle manipulation of &address in
huge_pmd_unshare will result in only one call if the unshare is successful,
but if unsuccessful we will unnecessarily call huge_pmd_unshare for each
address in the range.
Maybe we start by rounding up vm_start by PUD_SIZE and rounding down
vm_end by PUD_SIZE.
> + mmu_notifier_range_init(&range, MMU_NOTIFY_HUGETLB_UNSHARE,
> + 0, vma, mm, vma->vm_start, vma->vm_end);
> + mmu_notifier_invalidate_range_start(&range);
> + i_mmap_lock_write(vma->vm_file->f_mapping);
> + for (address = vma->vm_start; address < vma->vm_end; address += sz) {
Then, change the loop increment to PUD_SIZE. And, also ignore the &address
manipulation done by huge_pmd_unshare.
> + ptep = huge_pte_offset(mm, address, sz);
> + if (!ptep)
> + continue;
> + ptl = huge_pte_lock(h, mm, ptep);
> + huge_pmd_unshare(mm, vma, &address, ptep);
> + spin_unlock(ptl);
> + }
> + flush_hugetlb_tlb_range(vma, vma->vm_start, vma->vm_end);
> + i_mmap_unlock_write(vma->vm_file->f_mapping);
> + /*
> + * No need to call mmu_notifier_invalidate_range(), see
> + * Documentation/vm/mmu_notifier.rst.
> + */
> + mmu_notifier_invalidate_range_end(&range);
> +#endif
> +}
> +
> static void __wake_userfault(struct userfaultfd_ctx *ctx,
> struct userfaultfd_wake_range *range)
> {
> @@ -1449,6 +1494,9 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx,
> vma->vm_flags = new_flags;
> vma->vm_userfaultfd_ctx.ctx = ctx;
>
> + if (is_vm_hugetlb_page(vma) && uffd_disable_huge_pmd_share(vma))
> + hugetlb_unshare_all_pmds(vma);
> +
> skip:
> prev = vma;
> start = vma->vm_end;
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index b8200782dede..ff50c8528113 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -51,6 +51,7 @@ enum mmu_notifier_event {
> MMU_NOTIFY_SOFT_DIRTY,
> MMU_NOTIFY_RELEASE,
> MMU_NOTIFY_MIGRATE,
> + MMU_NOTIFY_HUGETLB_UNSHARE,
I don't claim to know much about mmu notifiers. Currently, we use other
event notifiers such as MMU_NOTIFY_CLEAR. I guess we do 'clear' page table
entries if we unshare. More than happy to have a MMU_NOTIFY_HUGETLB_UNSHARE
event, but will consumers of the notifications know what this new event type
means? And, if we introduce this should we use this other places where
huge_pmd_unshare is called?
--
Mike Kravetz
> };
>
> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
>
next prev parent reply other threads:[~2021-02-12 18:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 21:21 [PATCH v5 00/10] userfaultfd: add minor fault handling Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 01/10] hugetlb: Pass vma into huge_pte_alloc() and huge_pmd_share() Axel Rasmussen
2021-02-11 23:59 ` Mike Kravetz
2021-02-10 21:21 ` [PATCH v5 02/10] hugetlb/userfaultfd: Forbid huge pmd sharing when uffd enabled Axel Rasmussen
2021-02-12 0:19 ` Mike Kravetz
2021-02-12 20:40 ` Peter Xu
2021-02-12 20:47 ` Axel Rasmussen
2021-02-12 21:27 ` Mike Kravetz
2021-02-10 21:21 ` [PATCH v5 03/10] mm/hugetlb: Move flush_hugetlb_tlb_range() into hugetlb.h Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 04/10] hugetlb/userfaultfd: Unshare all pmds for hugetlbfs when register wp Axel Rasmussen
2021-02-12 18:11 ` Mike Kravetz [this message]
2021-02-12 21:18 ` Peter Xu
2021-02-12 21:34 ` Mike Kravetz
2021-02-12 22:14 ` Peter Xu
2021-02-10 21:21 ` [PATCH v5 05/10] userfaultfd: add minor fault registration mode Axel Rasmussen
2021-02-11 19:28 ` Axel Rasmussen
2021-02-11 20:58 ` Axel Rasmussen
2021-02-12 22:21 ` Matthew Wilcox
2021-02-12 22:44 ` Peter Xu
2021-02-12 22:51 ` Axel Rasmussen
2021-02-12 23:01 ` Peter Xu
2021-02-12 19:17 ` Mike Kravetz
2021-02-12 19:33 ` Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 06/10] userfaultfd: disable huge PMD sharing for MINOR registered VMAs Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 07/10] userfaultfd: hugetlbfs: only compile UFFD helpers if config enabled Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 08/10] userfaultfd: add UFFDIO_CONTINUE ioctl Axel Rasmussen
2021-02-10 22:21 ` Axel Rasmussen
2021-02-10 21:21 ` [PATCH v5 09/10] userfaultfd: update documentation to describe minor fault handling Axel Rasmussen
2021-02-10 21:22 ` [PATCH v5 10/10] userfaultfd/selftests: add test exercising " Axel Rasmussen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517f3477-cb80-6dc9-bda0-b147dea68f95@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=aarcange@redhat.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=anshuman.khandual@arm.com \
--cc=axelrasmussen@google.com \
--cc=cannonmatthews@google.com \
--cc=catalin.marinas@arm.com \
--cc=chinwen.chang@mediatek.com \
--cc=dgilbert@redhat.com \
--cc=jannh@google.com \
--cc=jglisse@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=oupton@google.com \
--cc=peterx@redhat.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=ruprecht@google.com \
--cc=shawn@anastas.io \
--cc=shli@fb.com \
--cc=steven.price@arm.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=walken@google.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).