All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>
Cc: Nadav Amit <nadav.amit@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Xu <peterx@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Nadav Amit <namit@vmware.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>, Jan Kara <jack@suse.cz>,
	stable@vger.kernel.org
Subject: Re: [PATCH] mm/userfaultfd: provide unmasked address on page-fault
Date: Sun, 10 Oct 2021 08:29:18 +0300	[thread overview]
Message-ID: <YWJ6Lv4QpJ3Kzynt@linux.ibm.com> (raw)
In-Reply-To: <d5a244e9-a04e-8794-e55f-380db5e8c6c4@redhat.com>

On Fri, Oct 08, 2021 at 10:05:36AM +0200, David Hildenbrand wrote:
> On 08.10.21 01:50, 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.
> > 
> > 	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
> > 
> > Add a new "real_address" field to vmf to hold the unmasked address. It
> > is possible to keep the unmasked address in the existing address field
> > (and mask whenever necessary) instead, but this is likely to cause
> > backporting problems of this patch.
> 
> Can we be sure that no existing users will rely on this behavior that has
> been the case since end of 2016 IIRC, one year after UFFD was upstreamed? I
> do wonder what the official ABI nowadays is, because man pages aren't
> necessarily the source of truth.
> 
> I checked QEMU (postcopy live migration), and I think it should be fine with
> this change.

CRIU is Ok with this change, we anyway mask the address.
 
-- 
Sincerely yours,
Mike.


      parent reply	other threads:[~2021-10-10  5:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-07 23:50 [PATCH] mm/userfaultfd: provide unmasked address on page-fault Nadav Amit
2021-10-08  8:05 ` David Hildenbrand
2021-10-08 22:02   ` Nadav Amit
2021-10-09  7:59     ` David Hildenbrand
2021-10-10  5:29   ` Mike Rapoport [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=YWJ6Lv4QpJ3Kzynt@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-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.com \
    --cc=namit@vmware.com \
    --cc=peterx@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.