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 BF57CC433EF for ; Mon, 21 Feb 2022 06:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38CB48D0001; Mon, 21 Feb 2022 01:28:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 314716B0073; Mon, 21 Feb 2022 01:28:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18DD58D0001; Mon, 21 Feb 2022 01:28:57 -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 047966B0072 for ; Mon, 21 Feb 2022 01:28:57 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id B8DAC1202EF for ; Mon, 21 Feb 2022 06:28:56 +0000 (UTC) X-FDA: 79165809072.04.CF38A4D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 38595180006 for ; Mon, 21 Feb 2022 06:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645424935; 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=M9RefAqRB0jpn0z55woIoiMzlSzsom48mirnPAWMkwU=; b=JAlfLSA8hjDU8yqUAnp+adP95bY1HFxhPWCdlMFyxZu8vXLgmbzUo9Uyy8n/vOneS8Tzqr X0yzVkKeKB885oC3VLnczY8qr4wLtyesUc4AMulOrAWIKoBlN7lZmTg/qyVC8fXh92cTy9 PZIy2dGm433j3QDw0GG0wKFXiE5IV50= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-404-MU7GisouOGeDQAKsO650Yw-1; Mon, 21 Feb 2022 01:28:53 -0500 X-MC-Unique: MU7GisouOGeDQAKsO650Yw-1 Received: by mail-pj1-f71.google.com with SMTP id lw18-20020a17090b181200b001bbfba1e6d2so2239458pjb.0 for ; Sun, 20 Feb 2022 22:28:53 -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=M9RefAqRB0jpn0z55woIoiMzlSzsom48mirnPAWMkwU=; b=fnzgBy88By4tKKisqOGYhxJMhFa6Z4I2dJPhtP3nq5OpGN4jHxz9wSgbmrsatbkohl 8PbI6AKHwtF1d05ykkwTo/xYlXuu4JVpZ++fFghTbln2QJS2J6yMQRlHG02E9oyBC3ID M7H0gQ/NNeiJx/Ap+8crxNGa7/aujHs0SHvyc7HhR4857pe7zUR10fp0pV3MtswcM1t3 KZGxT9VwxK7wVQ0H4M4ydQJvPibbVJ5o7lV5LccRvTk6mclRNPyBK2aLVzL2CTovk5+i Z04yj76NMM9nE7fR+Klcpsgw3Efsu0hbfpw/qaTaYo3s2fE/5fZAUELIdQwwcNSJV03F Yc4Q== X-Gm-Message-State: AOAM531aduMJvTJBjsDHahN3OVglqKPTITs1cinPJnRPlrdjhsaz+fDl p6d5ycaCC0NXTuOKE3pzUYabr8FwmVpCEw4O2KvhultawJB/Qk6GYIBvox8MYw8ilfqQzXNqcy8 fu1A77uJ4BqY= X-Received: by 2002:a63:5525:0:b0:372:c376:74f1 with SMTP id j37-20020a635525000000b00372c37674f1mr14939804pgb.433.1645424932914; Sun, 20 Feb 2022 22:28:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJybFAx7SXfeOEwRddcrxmOfZc4tp70V8ODGboqqeTLTaa5r/gH3wrNcbQP4gu42nQXNUmhugg== X-Received: by 2002:a63:5525:0:b0:372:c376:74f1 with SMTP id j37-20020a635525000000b00372c37674f1mr14939794pgb.433.1645424932648; Sun, 20 Feb 2022 22:28:52 -0800 (PST) Received: from xz-m1.local ([191.101.132.225]) by smtp.gmail.com with ESMTPSA id q93-20020a17090a4fe600b001b9ba2a1dc3sm6301593pjh.25.2022.02.20.22.28.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 20 Feb 2022 22:28:52 -0800 (PST) Date: Mon, 21 Feb 2022 14:28:47 +0800 From: Peter Xu To: Nadav Amit Cc: Andrew Morton , linux-mm@kvack.org, Nadav Amit , David Hildenbrand , Andrea Arcangeli , Mike Rapoport , Jan Kara Subject: Re: [PATCH v2] userfaultfd: provide unmasked address on page-fault Message-ID: References: <20220218041003.3508-1-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: <20220218041003.3508-1-namit@vmware.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JAlfLSA8; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 38595180006 X-Stat-Signature: yr91gkwrd8phbs56r84hcmxsque53pjw X-HE-Tag: 1645424936-131716 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 Fri, Feb 18, 2022 at 04:10:03AM +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. > > Cc: David Hildenbrand > Cc: Andrea Arcangeli > Cc: Mike Rapoport > Cc: Peter Xu > Cc: Jan Kara > Signed-off-by: Nadav Amit Acked-by: Peter Xu -- Peter Xu