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 E7BC1C433EF for ; Thu, 3 Mar 2022 08:03:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 502048D0002; Thu, 3 Mar 2022 03:03:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B1A18D0001; Thu, 3 Mar 2022 03:03:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3793C8D0002; Thu, 3 Mar 2022 03:03:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 248CA8D0001 for ; Thu, 3 Mar 2022 03:03:29 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D392120418 for ; Thu, 3 Mar 2022 08:03:28 +0000 (UTC) X-FDA: 79202335296.12.E8C069F 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 467AB1A0010 for ; Thu, 3 Mar 2022 08:03:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646294607; 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: in-reply-to:in-reply-to:references:references; bh=tstKDs7f+YbHwk1IssFU+DMF1NZio70a5r1vw+1TifA=; b=A0jg2HjjQojj/3nzVxbiEYY9iEOvicrRoH8fw+a9lSkRujnn6df7POZj9OtCHAPCNANJ59 QOh9Rezxcg7IMEjDnHGemzmeeNAIPvk0MSWrocP1hiDUhtprpkTrWT/PZG6u0ttyYg0xlq uoGKzFEPcFzfEx5LRy7l+74UnREXy90= Received: from mail-pg1-f199.google.com (mail-pg1-f199.google.com [209.85.215.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-193-ZBdhhrdLN_mze6NpZXp77g-1; Thu, 03 Mar 2022 03:03:26 -0500 X-MC-Unique: ZBdhhrdLN_mze6NpZXp77g-1 Received: by mail-pg1-f199.google.com with SMTP id t68-20020a635f47000000b003732348b971so2416707pgb.7 for ; Thu, 03 Mar 2022 00:03:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tstKDs7f+YbHwk1IssFU+DMF1NZio70a5r1vw+1TifA=; b=MPpvlvyZXO7U1mTQxp73Gpr0Hmd6HnMgSKO/l3NvmZpUg8nsCweP6yZfZFKp2RJJOr WV287vHbRqtaHoeO9s/pfcDYsHpPQwqriX2ROgjdnopztJZduP4PC7Cedln8L5fG7n3s c7/JndI/qt88WcwbFDJX0s0DJfarhB43C4h/lLHgKTD3BoEZYurPhxs0bJtLQOxuIiWm EN3CBkuJ7yo3EhMNXlC3rEHu280z4cY8a+3EUJJyeECGfqak7Us2sFkCkaCq+/hqCj8B 6s8w3WNWPPpBgjrTdqwBsB+H9P+5bKBOisGLW7z4d8MhoW0ACjVkI/RGJs1KFfYToJE+ MjcQ== X-Gm-Message-State: AOAM532XRv0OdThIr1f9g5jt3lgr5wdw+mXGfdeIleMw57As999RIFxd 5mzI8l7F/kFBXsjUPBJYDN2Hlyy3Va0Ozi2H8iT7mSS8W0vSrpDU5q1LMiM16boky5aXawGusNC PRUHwgzvXU2U= X-Received: by 2002:a63:d711:0:b0:373:d6e7:e78c with SMTP id d17-20020a63d711000000b00373d6e7e78cmr28867777pgg.121.1646294605488; Thu, 03 Mar 2022 00:03:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJy4bZd/jXVxxboTwD2xvCJWGkYiGTuEbvPqWpiUVzGHbPW4Yqdg9Lx1kYeBzEh06Qtz4kK0/g== X-Received: by 2002:a63:d711:0:b0:373:d6e7:e78c with SMTP id d17-20020a63d711000000b00373d6e7e78cmr28867749pgg.121.1646294604929; Thu, 03 Mar 2022 00:03:24 -0800 (PST) Received: from xz-m1.local ([94.177.118.101]) by smtp.gmail.com with ESMTPSA id a8-20020aa795a8000000b004f670c2ef2esm1231898pfk.163.2022.03.03.00.03.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Mar 2022 00:03:24 -0800 (PST) Date: Thu, 3 Mar 2022 16:03:15 +0800 From: Peter Xu To: Nadav Amit , Andrew Morton Cc: linux-mm@kvack.org, Nadav Amit , David Hildenbrand , Andrea Arcangeli , Mike Rapoport , Jan Kara Subject: Re: [PATCH v3] userfaultfd: provide unmasked address on page-fault Message-ID: References: <20220226022655.350562-1-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: <20220226022655.350562-1-namit@vmware.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: pfo4sp7bfbpqiyp5hfiwccbzenmq8u1f Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=A0jg2Hjj; spf=none (imf19.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Queue-Id: 467AB1A0010 X-HE-Tag: 1646294608-283000 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 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 provides > 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() = 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 > > The exact address is useful for various reasons and specifically for > prefetching decisions. If it is known that the memory is populated by > certain objects whose size is not page-aligned, then based on the > faulting address, the uffd-monitor can decide whether to prefetch and > 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_address") > vmf->virtual_address"), which dates back to 2016. A concern has been > raised that existing userspace application might rely on the old/wrong > behavior in which the address is masked. Therefore, it was suggested to > provide the masked address unless the user explicitly asks for the exact > address. > > Add a new userfaultfd feature UFFD_FEATURE_EXACT_ADDRESS to direct > userfaultfd to provide the exact address. Add a new "real_address" field > to vmf to hold the unmasked address. Provide the address to userspace > 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 think, while the queued one is the old version. IOW, uffd is currently broken on latest linux-next on hugetlb. Thanks, -- Peter Xu