From: Mike Rapoport <rppt@linux.ibm.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Nadav Amit <namit@vmware.com>,
David Hildenbrand <david@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
Peter Xu <peterx@redhat.com>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v2] userfaultfd: provide unmasked address on page-fault
Date: Mon, 21 Feb 2022 18:20:24 +0200 [thread overview]
Message-ID: <YhO7yA7IurD6IIgG@linux.ibm.com> (raw)
In-Reply-To: <20220218041003.3508-1-namit@vmware.com>
On Fri, Feb 18, 2022 at 04:10:03AM +0000, Nadav Amit wrote:
> From: Nadav Amit <namit@vmware.com>
>
> Userfaultfd is supposed to provide the full address (i.e., unmasked) of
> the faulting access back to userspace. However, that is not the case for
> quite some time.
>
> Even running "userfaultfd_demo" from the userfaultfd man page provides
> the wrong output (and contradicts the man page). Notice that
> "UFFD_EVENT_PAGEFAULT event" shows the masked address (7fc5e30b3000)
> and not the first read address (0x7fc5e30b300f).
>
> Address returned by mmap() = 0x7fc5e30b3000
>
> fault_handler_thread():
> poll() returns: nready = 1; POLLIN = 1; POLLERR = 0
> UFFD_EVENT_PAGEFAULT event: flags = 0; address = 7fc5e30b3000
> (uffdio_copy.copy returned 4096)
> Read address 0x7fc5e30b300f in main(): A
> Read address 0x7fc5e30b340f in main(): A
> Read address 0x7fc5e30b380f in main(): A
> Read address 0x7fc5e30b3c0f in main(): A
>
> The exact address is useful for various reasons and specifically for
> prefetching decisions. If it is known that the memory is populated by
> certain objects whose size is not page-aligned, then based on the
> faulting address, the uffd-monitor can decide whether to prefetch and
> prefault the adjacent page.
>
> This bug has been for quite some time in the kernel: since commit
> 1a29d85eb0f1 ("mm: use vmf->address instead of of vmf->virtual_address")
> vmf->virtual_address"), which dates back to 2016. A concern has been
> raised that existing userspace application might rely on the old/wrong
> behavior in which the address is masked. Therefore, it was suggested to
> provide the masked address unless the user explicitly asks for the exact
> address.
>
> Add a new userfaultfd feature UFFD_FEATURE_EXACT_ADDRESS to direct
> userfaultfd to provide the exact address. Add a new "real_address" field
> to vmf to hold the unmasked address. Provide the address to userspace
> accordingly.
>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Peter Xu <peterx@redhat.com>
> Cc: Jan Kara <jack@suse.cz>
> Signed-off-by: Nadav Amit <namit@vmware.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
>
> ---
>
> v1->v2:
> * Add uffd feature to selectively enable [David, Andrea]
> ---
> fs/userfaultfd.c | 5 ++++-
> include/linux/mm.h | 3 ++-
> include/uapi/linux/userfaultfd.h | 8 +++++++-
> mm/memory.c | 1 +
> 4 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index e26b10132d47..826927026fe7 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -198,6 +198,9 @@ static inline struct uffd_msg userfault_msg(unsigned long address,
> struct uffd_msg msg;
> msg_init(&msg);
> msg.event = UFFD_EVENT_PAGEFAULT;
> +
> + if (!(features & UFFD_FEATURE_EXACT_ADDRESS))
> + address &= PAGE_MASK;
> msg.arg.pagefault.address = address;
> /*
> * These flags indicate why the userfault occurred:
> @@ -482,7 +485,7 @@ vm_fault_t handle_userfault(struct vm_fault *vmf, unsigned long reason)
>
> init_waitqueue_func_entry(&uwq.wq, userfaultfd_wake_function);
> uwq.wq.private = current;
> - uwq.msg = userfault_msg(vmf->address, vmf->flags, reason,
> + uwq.msg = userfault_msg(vmf->real_address, vmf->flags, reason,
> ctx->features);
> uwq.ctx = ctx;
> uwq.waken = false;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 213cc569b192..27df0ca0a36a 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -478,7 +478,8 @@ struct vm_fault {
> struct vm_area_struct *vma; /* Target VMA */
> gfp_t gfp_mask; /* gfp mask to be used for allocations */
> pgoff_t pgoff; /* Logical page offset based on vma */
> - unsigned long address; /* Faulting virtual address */
> + unsigned long address; /* Faulting virtual address - masked */
> + unsigned long real_address; /* Faulting virtual address - unmaked */
> };
> enum fault_flag flags; /* FAULT_FLAG_xxx flags
> * XXX: should really be 'const' */
> diff --git a/include/uapi/linux/userfaultfd.h b/include/uapi/linux/userfaultfd.h
> index 05b31d60acf6..ef739054cb1c 100644
> --- a/include/uapi/linux/userfaultfd.h
> +++ b/include/uapi/linux/userfaultfd.h
> @@ -32,7 +32,8 @@
> UFFD_FEATURE_SIGBUS | \
> UFFD_FEATURE_THREAD_ID | \
> UFFD_FEATURE_MINOR_HUGETLBFS | \
> - UFFD_FEATURE_MINOR_SHMEM)
> + UFFD_FEATURE_MINOR_SHMEM | \
> + UFFD_FEATURE_EXACT_ADDRESS)
> #define UFFD_API_IOCTLS \
> ((__u64)1 << _UFFDIO_REGISTER | \
> (__u64)1 << _UFFDIO_UNREGISTER | \
> @@ -189,6 +190,10 @@ struct uffdio_api {
> *
> * UFFD_FEATURE_MINOR_SHMEM indicates the same support as
> * UFFD_FEATURE_MINOR_HUGETLBFS, but for shmem-backed pages instead.
> + *
> + * UFFD_FEATURE_EXACT_ADDRESS indicates that the exact address of page
> + * faults would be provided and the offset within the page would not be
> + * masked.
> */
> #define UFFD_FEATURE_PAGEFAULT_FLAG_WP (1<<0)
> #define UFFD_FEATURE_EVENT_FORK (1<<1)
> @@ -201,6 +206,7 @@ struct uffdio_api {
> #define UFFD_FEATURE_THREAD_ID (1<<8)
> #define UFFD_FEATURE_MINOR_HUGETLBFS (1<<9)
> #define UFFD_FEATURE_MINOR_SHMEM (1<<10)
> +#define UFFD_FEATURE_EXACT_ADDRESS (1<<11)
> __u64 features;
>
> __u64 ioctls;
> diff --git a/mm/memory.c b/mm/memory.c
> index c125c4969913..aae53fde13d9 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4622,6 +4622,7 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma,
> struct vm_fault vmf = {
> .vma = vma,
> .address = address & PAGE_MASK,
> + .real_address = address,
> .flags = flags,
> .pgoff = linear_page_index(vma, address),
> .gfp_mask = __get_fault_gfp_mask(vma),
> --
> 2.25.1
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-02-21 16:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 4:10 [PATCH v2] userfaultfd: provide unmasked address on page-fault Nadav Amit
2022-02-21 6:28 ` Peter Xu
2022-02-21 15:31 ` David Hildenbrand
2022-02-21 16:20 ` Mike Rapoport [this message]
2022-02-22 5:02 ` Andrew Morton
2022-02-22 9:00 ` Jan Kara
2022-02-23 4:58 ` Nadav Amit
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=YhO7yA7IurD6IIgG@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=jack@suse.cz \
--cc=linux-mm@kvack.org \
--cc=nadav.amit@gmail.com \
--cc=namit@vmware.com \
--cc=peterx@redhat.com \
--cc=rppt@linux.vnet.ibm.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).