From: Mike Rapoport <rppt@linux.ibm.com>
To: Blake Caldwell <blake.caldwell@colorado.edu>
Cc: rppt@linux.vnet.ibm.com, xemul@virtuozzo.com,
akpm@linux-foundation.org, mike.kravetz@oracle.com,
kirill.shutemov@linux.intel.com, linux-mm@kvack.org,
aarcange@redhat.com
Subject: Re: [PATCH 4/4] userfaultfd: change the direction for UFFDIO_REMAP to out
Date: Sun, 20 Jan 2019 23:07:32 +0200 [thread overview]
Message-ID: <20190120210731.GC28141@rapoport-lnx> (raw)
In-Reply-To: <ab1b6be85254e111935104cf4a2293ab2fa4a8d6.1547251023.git.blake.caldwell@colorado.edu>
Hi,
On Sat, Jan 12, 2019 at 12:36:29AM +0000, Blake Caldwell wrote:
> Moving a page out of a userfaultfd registered region and into a userland
> anonymous vma is needed by the use case of uncooperatively limiting the
> resident size of the userfaultfd region. Reverse the direction of the
> original userfaultfd_remap() to the out direction. Now after memory has
> been removed, subsequent accesses will generate uffdio page fault events.
It took me a while but better late then never :)
Why did you keep this as a separate patch? If the primary use case for
UFFDIO_REMAP to move pages out of userfaultfd region, why not make it so
from the beginning?
> Signed-off-by: Blake Caldwell <blake.caldwell@colorado.edu>
> ---
> Documentation/admin-guide/mm/userfaultfd.rst | 10 ++++++++++
> fs/userfaultfd.c | 6 +++---
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst
> index 5048cf6..714af49 100644
> --- a/Documentation/admin-guide/mm/userfaultfd.rst
> +++ b/Documentation/admin-guide/mm/userfaultfd.rst
> @@ -108,6 +108,16 @@ UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an
> half copied page since it'll keep userfaulting until the copy has
> finished.
>
> +To move pages out of a userfault registered region and into a user vma
> +the UFFDIO_REMAP ioctl can be used. This is only possible for the
> +"OUT" direction. For the "IN" direction, UFFDIO_COPY is preferred
> +since UFFDIO_REMAP requires a TLB flush on the source range at a
> +greater penalty than copying the page. With
> +UFFDIO_REGISTER_MODE_MISSING set, subsequent accesses to the same
> +region will generate a page fault event. This allows non-cooperative
> +removal of memory in a userfaultfd registered vma, effectively
> +limiting the amount of resident memory in such a region.
> +
> QEMU/KVM
> ========
>
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index cf68cdb..8099da2 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -1808,10 +1808,10 @@ static int userfaultfd_remap(struct userfaultfd_ctx *ctx,
> sizeof(uffdio_remap)-sizeof(__s64)))
> goto out;
>
> - ret = validate_range(ctx->mm, uffdio_remap.dst, uffdio_remap.len);
> + ret = validate_range(current->mm, uffdio_remap.dst, uffdio_remap.len);
> if (ret)
> goto out;
> - ret = validate_range(current->mm, uffdio_remap.src, uffdio_remap.len);
> + ret = validate_range(ctx->mm, uffdio_remap.src, uffdio_remap.len);
> if (ret)
> goto out;
> ret = -EINVAL;
> @@ -1819,7 +1819,7 @@ static int userfaultfd_remap(struct userfaultfd_ctx *ctx,
> UFFDIO_REMAP_MODE_DONTWAKE))
> goto out;
>
> - ret = remap_pages(ctx->mm, current->mm,
> + ret = remap_pages(current->mm, ctx->mm,
> uffdio_remap.dst, uffdio_remap.src,
> uffdio_remap.len, uffdio_remap.mode);
> if (unlikely(put_user(ret, &user_uffdio_remap->remap)))
> --
> 1.8.3.1
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2019-01-20 21:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-12 0:36 [PATCH 0/4] RFC: userfaultfd remap Blake Caldwell
2019-01-12 0:36 ` [PATCH 1/4] userfaultfd: UFFDIO_REMAP: rmap preparation Blake Caldwell
2019-01-12 0:36 ` [PATCH 2/4] userfaultfd: UFFDIO_REMAP uABI Blake Caldwell
2019-01-12 0:36 ` [PATCH 3/4] userfaultfd: UFFDIO_REMAP Blake Caldwell
2019-01-12 0:36 ` [PATCH 4/4] userfaultfd: change the direction for UFFDIO_REMAP to out Blake Caldwell
2019-01-20 21:07 ` Mike Rapoport [this message]
2019-01-24 23:36 ` Blake Caldwell
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=20190120210731.GC28141@rapoport-lnx \
--to=rppt@linux.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=blake.caldwell@colorado.edu \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=rppt@linux.vnet.ibm.com \
--cc=xemul@virtuozzo.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