From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4801DC433EF for ; Fri, 4 Mar 2022 10:38:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 577678D0002; Fri, 4 Mar 2022 05:38:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5263A8D0001; Fri, 4 Mar 2022 05:38:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EE058D0002; Fri, 4 Mar 2022 05:38:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 2BB168D0001 for ; Fri, 4 Mar 2022 05:38:53 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id DB6729A26E for ; Fri, 4 Mar 2022 10:38:52 +0000 (UTC) X-FDA: 79206355704.17.AF1BB8A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 4EEFA1A0017 for ; Fri, 4 Mar 2022 10:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646390331; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RZYOIkeCgAKFP7FMq6mSIh4G9tM2Ax71NGKqWNUjEw8=; b=fIRbc4KS09pLnXRmnqhq3yO/Oz2U7QzffnDs79iETUP7dbLtkaqR/unBwDk5Oh+6inkHLR neBqGYmz8EKZvRdQ7PWIsK2aSnSssFDD36pfDJPreJM3JJ+SxPYnoBvf2bYx9H+x+NbNU9 FyX9l4mNtqcRq47GXl038Y27Yzl0qDs= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-477-JoM19gjyMVm62ESN_J6xfA-1; Fri, 04 Mar 2022 05:38:48 -0500 X-MC-Unique: JoM19gjyMVm62ESN_J6xfA-1 Received: by mail-wr1-f71.google.com with SMTP id f14-20020adfc98e000000b001e8593b40b0so3193766wrh.14 for ; Fri, 04 Mar 2022 02:38:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=RZYOIkeCgAKFP7FMq6mSIh4G9tM2Ax71NGKqWNUjEw8=; b=2zMcCti1+fw4dJFld8sioYOIkEFymYGyt8R1GVQPOTHinp45VhZt8dO+0Ht/24emJH nikkXzQlaOnkeQEsA5iZL7KHlKGGW9SyUQRi5P15Lr1SqLVGZaegsQO71rY013Tgx7Gj 2gP1PXHc2uh2ga6KqK2AirbgmZLEC35SAZKn00uDlIXsAnGHsruiU2QBJgeWPOcqm5zI XK7BBZu7DjIHjPxpcYXVsTue0kFwI87Uu8RHiGl90KQc6OFNEgniqMzfqS3A/5kdqG+I 71kpObqgzHrb28YBZXHKTfeIXSS2rzPdwtcVHz5POv8pldJ+/MzkHDqZizoOS9GdD9YQ epWA== X-Gm-Message-State: AOAM532K52gezlt7C8OyKZ9tJTScG7Nl0TbPBwrVMpbxJT+eVnTu0pgj uGvy9YQ7VMrWlG2lesLU1mx3X392XBqx4hgu2mg+bHWDnpFL3X/2MtHF6ASER4WXRHjVBX8t5Mu mfLevZl/BEG0= X-Received: by 2002:a05:6000:16ce:b0:1ef:d619:d92a with SMTP id h14-20020a05600016ce00b001efd619d92amr17523499wrf.463.1646390327335; Fri, 04 Mar 2022 02:38:47 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8n7hRfIf2T+SqipYeObmK4k589UhEd+OAZthQJ3VferoGT3P92nNV+OXsz1QqXDOTtJntEQ== X-Received: by 2002:a05:6000:16ce:b0:1ef:d619:d92a with SMTP id h14-20020a05600016ce00b001efd619d92amr17523479wrf.463.1646390327059; Fri, 04 Mar 2022 02:38:47 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:20af:34be:985b:b6c8? ([2a09:80c0:192:0:20af:34be:985b:b6c8]) by smtp.gmail.com with ESMTPSA id f8-20020a05600c4e8800b00380ee4a78fdsm5762176wmq.4.2022.03.04.02.38.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Mar 2022 02:38:46 -0800 (PST) Message-ID: Date: Fri, 4 Mar 2022 11:38:45 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] userfaultfd: provide unmasked address on page-fault To: Nadav Amit , Peter Xu Cc: Andrew Morton , Linux-MM , Andrea Arcangeli , Mike Rapoport , Jan Kara References: <20220226022655.350562-1-namit@vmware.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4EEFA1A0017 X-Stat-Signature: s1s35xpkaice859mn4wbitiz441nzotm Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=fIRbc4KS; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf19.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1646390332-923900 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 03.03.22 20:51, Nadav Amit wrote: >=20 >=20 >> On Mar 3, 2022, at 11:05 AM, Nadav Amit wrote: >> >> >> >>> On Mar 3, 2022, at 12:03 AM, Peter Xu wrote: >>> >>> On Sat, Feb 26, 2022 at 02:26:55AM +0000, Nadav Amit wrote: >>>> From: Nadav Amit >>>> >>>> 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 provid= es >>>> the wrong output (and contradicts the man page). Notice that >>>> "UFFD_EVENT_PAGEFAULT event" shows the masked address (7fc5e30b3000) >>>> and not the first read address (0x7fc5e30b300f). >>>> >>>> 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 7fc5e30b30= 00 >>>> (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 >>>> >>>> The exact address is useful for various reasons and specifically for >>>> prefetching decisions. If it is known that the memory is populated b= y >>>> certain objects whose size is not page-aligned, then based on the >>>> faulting address, the uffd-monitor can decide whether to prefetch an= d >>>> prefault the adjacent page. >>>> >>>> This bug has been for quite some time in the kernel: since commit >>>> 1a29d85eb0f1 ("mm: use vmf->address instead of of vmf->virtual_addre= ss") >>>> vmf->virtual_address"), which dates back to 2016. A concern has been >>>> raised that existing userspace application might rely on the old/wro= ng >>>> behavior in which the address is masked. Therefore, it was suggested= to >>>> provide the masked address unless the user explicitly asks for the e= xact >>>> address. >>>> >>>> Add a new userfaultfd feature UFFD_FEATURE_EXACT_ADDRESS to direct >>>> userfaultfd to provide the exact address. Add a new "real_address" f= ield >>>> to vmf to hold the unmasked address. Provide the address to userspac= e >>>> accordingly. >>>> >>>> Initialize real_address in various code-paths to be consistent with >>>> address, even when it is not used, to be on the safe side. >>>> >>>> Acked-by: Peter Xu >>>> Reviewed-by: David Hildenbrand >>>> Cc: Andrea Arcangeli >>>> Cc: Mike Rapoport >>>> Cc: Jan Kara >>>> Signed-off-by: Nadav Amit >>> >>> Hi, Andrew, >>> >>> Just a heads-up that this version has not yet been updated in -mm I t= hink, >>> while the queued one is the old version. >>> >>> IOW, uffd is currently broken on latest linux-next on hugetlb. >> >> Thanks Peter for reminding Andrew. >> >> Andrew, please acknowledge it would be queue for the next version and >> I will submit a patch to the man pages. >=20 > Peter (et. al), >=20 > I=E2=80=99ll send it in a more orderly fashion later, but let me know i= f I got > something completely wrong for the man page change: >=20 > [ Thanks as usual; sorry - limited experience changing man pages ] >=20 > -- >8 -- >=20 > From: Nadav Amit > Date: Thu, 3 Mar 2022 19:44:37 +0000 > Subject: [PATCH] ioctl_userfaultfd: add UFFD_FEATURE_EXACT_ADDRESS >=20 > Describe the new UFFD_FEATURE_EXACT_ADDRESS API feature. >=20 > Signed-off-by: Nadav Amit > --- > man2/ioctl_userfaultfd.2 | 6 ++++++ > 1 file changed, 6 insertions(+) >=20 > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > index 504f61d4b..2d065504e 100644 > --- a/man2/ioctl_userfaultfd.2 > +++ b/man2/ioctl_userfaultfd.2 > @@ -214,6 +214,12 @@ memory accesses to the regions registered with use= rfaultfd. > If this feature bit is set, > .I uffd_msg.pagefault.feat.ptid > will be set to the faulted thread ID for each page-fault message. > +.TP > +.BR UFFD_FEATURE_EXACT_ADDRESS " (since Linux 5.18)" > +If this feature bit is set, > +.I uffd_msg.pagefault.address > +will be set to the exact page-fault address that was reported by the h= ardware, > +and will not mask the offset within the page. > .PP > The returned > .I ioctls Do we want to add a comment about early uffd code that did this as well? "Note that old Linux versions might indicate the exact address as well, even though the feature bit is not set." --=20 Thanks, David / dhildenb