Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [PATCH] mm/userfaultfd: provide unmasked address on page-fault
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <d5a244e9-a04e-8794-e55f-380db5e8c6c4@redhat.com>
Date:   Fri, 8 Oct 2021 15:02:02 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Peter Xu <peterx@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        Jan Kara <jack@suse.cz>, stable@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2ADE3F0-74B1-4D1D-80AE-0BBC49D932E6@gmail.com>
References: <20211007235055.469587-1-namit@vmware.com>
 <d5a244e9-a04e-8794-e55f-380db5e8c6c4@redhat.com>
To:     David Hildenbrand <david@redhat.com>
Precedence: bulk


> On Oct 8, 2021, at 1:05 AM, David Hildenbrand <david@redhat.com> =
wrote:
>=20
> 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() =3D 0x7fc5e30b3000
>> 	fault_handler_thread():
>> 	    poll() returns: nready =3D 1; POLLIN =3D 1; POLLERR =3D 0
>> 	    UFFD_EVENT_PAGEFAULT event: flags =3D 0; address =3D =
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.
>=20
> 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?

Let me to blow off your mind: how do you be sure that the current =
behavior does not make applications to misbehave? It might cause =
performance issues as it did for me or hidden correctness issues.

> I do wonder what the official ABI nowadays is, because man pages =
aren't necessarily the source of truth.

Documentation/admin-guide/mm/userfaultfd.rst says: "You get the address =
of the access that triggered the missing page
event=E2=80=9D.

So it is a bug.