linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Blake Caldwell <blake.caldwell@colorado.edu>
To: Mike Rapoport <rppt@linux.ibm.com>
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: Thu, 24 Jan 2019 18:36:08 -0500	[thread overview]
Message-ID: <59078FED-5A1B-42D8-A501-975CE69CBC9B@colorado.edu> (raw)
In-Reply-To: <20190120210731.GC28141@rapoport-lnx>

[-- Attachment #1: Type: text/plain, Size: 3536 bytes --]


> On Jan 20, 2019, at 4:07 PM, Mike Rapoport <rppt@linux.ibm.com> wrote:
> 
> 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?

Only to show what has changed since this was last proposed, but yes, that
change to fs/userfaultfd.c should be squashed with patch 3. The purpose of
patch 4 will only be documenting UFFDIO_REMAP.

I will make those changes for the next revision. Thanks for looking this over.

> 
>> 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.


[-- Attachment #2: Type: text/html, Size: 15365 bytes --]

      reply	other threads:[~2019-01-24 23:36 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
2019-01-24 23:36     ` Blake Caldwell [this message]

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=59078FED-5A1B-42D8-A501-975CE69CBC9B@colorado.edu \
    --to=blake.caldwell@colorado.edu \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=rppt@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).