linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Evgeny Yakovlev <eyakovlev@virtuozzo.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: linux-mm@kvack.org, Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: userfaultfd: unexpected behavior with MODE_MISSING | MODE_WP regions
Date: Fri, 12 Aug 2016 16:43:05 +0300	[thread overview]
Message-ID: <9696fafa-dfcf-052a-e916-013508303dc2@virtuozzo.com> (raw)
In-Reply-To: <20160811171726.xlna3ni4dp2ed4a4@redhat.com>


Hello Andrea,

On 11.08.2016 20:17, Andrea Arcangeli wrote:
> Hello Evgeny,
>
> On Thu, Aug 11, 2016 at 04:51:30PM +0300, Evgeny Yakovlev wrote:
>>    * 1. First fault is expected UFFD_PAGEFAULT_FLAG_WRITE set which we
>> resolve
>>    * with zeropage
> What if you resolve it with bzero(4096);UFFDIO_COPY? Does the problem
> go away?

Yes, i don't see additional WP fault now, only expected missing write fault.

> If the zeropage is mapped by UFFDIO_ZEROPAGE, there's no way to turn
> that into a writable zeropage ever again because
> userfaultfd_writeprotect is basically a no-vma-mangling mmap_sem-read
> mprotect and it can't trigger faults. Instead a fault in do_wp_page is
> required to get rid of the zeropage and copy it off.

Maybe i am missing something but why do we then get WP faults on that 
page right after we UFFDIO_ZEROPAGE it? We never call writeprotect on 
zeropaged page and still get a WP fault on it which we can't resolve 
properly.

> If the problem goes away if you s/UFFDIO_ZEROPAGE/bzero(4096);
> UFFDIO_COPY/ as I would expect, there would be two ways to solve it:
>
> 1) forbid UFFDIO_ZEROPAGE and not return the UFFDIO_ZEROPAGE ioctl in
>     uffdio_register.ioctls, if UFFDIO_REGISTER is called with
>     uffdio_register.mode = ...WP|..MISSING so userland is aware it
>     can't use that.
>
> 2) teach UFFDIO_WRITEPROTECT not just to mangle pagetables but also
>     trigger a write fault on any zeropage if it's called with
>     uffdio_writeprotect.mode without UFFDIO_WRITEPROTECT_MODE_WP being
>     set. This will require a bit more work to fix.
>
> The latter would increase performance if not all zeropages needs to be
> turned writable.
>
> Feedback welcome on what solution would you prefer.

Our use case is as follows. We have a huge region and most of it we need 
to be writable. Most of the time we just gradually resolve missing 
faults as they appear. We only enable write protection on some selective 
already present pages to have a way to track attempted page modification 
for a short period of time. We register initial region as MISSING | WP 
so that we don't have to register a new page-sized region each time we 
need to write-protect a single page inside a region.

>
> Thanks,
> Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2016-08-12 13:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-11 13:51 Evgeny Yakovlev
2016-08-11 17:17 ` Andrea Arcangeli
2016-08-12 13:43   ` Evgeny Yakovlev [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=9696fafa-dfcf-052a-e916-013508303dc2@virtuozzo.com \
    --to=eyakovlev@virtuozzo.com \
    --cc=aarcange@redhat.com \
    --cc=linux-mm@kvack.org \
    --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