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 E6C02C433F5 for ; Tue, 22 Feb 2022 09:00:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3920C8D0002; Tue, 22 Feb 2022 04:00:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 341D68D0001; Tue, 22 Feb 2022 04:00:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 230908D0002; Tue, 22 Feb 2022 04:00:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 136DA8D0001 for ; Tue, 22 Feb 2022 04:00:06 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CB84C20B60 for ; Tue, 22 Feb 2022 09:00:05 +0000 (UTC) X-FDA: 79169818770.04.E5E0EEA Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf28.hostedemail.com (Postfix) with ESMTP id 27D35C0003 for ; Tue, 22 Feb 2022 09:00:03 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id D604221114; Tue, 22 Feb 2022 09:00:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1645520402; h=from:from:reply-to: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=oD+GphRLKp8evlZI83UPDr5DVtFNvygCMCMJlrzi6aw=; b=2kqddYKbe4+x8zsBahI2j1N6GPR0jBHxEe/sAAyNvGuUMZcNdwKULZnHQYiMyaq3OvsqaX IYVkJChAaxhdpV+d1gON/1404gGaieLJIaBmWmVBOOKXUlP7cdIjunpkAZCp0oywhVrH4l VVwPaXW6+XeR74GULdSlrYx0oGmT2UQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1645520402; h=from:from:reply-to: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=oD+GphRLKp8evlZI83UPDr5DVtFNvygCMCMJlrzi6aw=; b=nE3OtwMMmuUNCBrIbJbI7XnJxTeV/JOZlYtQ2a1U6oGdmYDhfyKA35fliU+gnhSFUAvXS+ z8XRdUYC5DqRMlBw== Received: from quack3.suse.cz (unknown [10.100.200.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id B8B86A3B88; Tue, 22 Feb 2022 09:00:02 +0000 (UTC) Received: by quack3.suse.cz (Postfix, from userid 1000) id 7B4CBA0606; Tue, 22 Feb 2022 10:00:02 +0100 (CET) Date: Tue, 22 Feb 2022 10:00:02 +0100 From: Jan Kara To: Nadav Amit Cc: Andrew Morton , linux-mm@kvack.org, Nadav Amit , David Hildenbrand , Andrea Arcangeli , Mike Rapoport , Peter Xu , Jan Kara Subject: Re: [PATCH v2] userfaultfd: provide unmasked address on page-fault Message-ID: <20220222090002.24lg2fdhrihquzaj@quack3.lan> References: <20220218041003.3508-1-namit@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220218041003.3508-1-namit@vmware.com> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 27D35C0003 X-Stat-Signature: aquqfzymmd7swpsuhia1mm1fkd8pnuq7 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=2kqddYKb; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=nE3OtwMM; spf=pass (imf28.hostedemail.com: domain of jack@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=jack@suse.cz; dmarc=none X-Rspam-User: X-HE-Tag: 1645520403-448160 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 18-02-22 04:10:03, 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 Yeah, I'm sorry for breaking this :-| The patch looks good except: > diff --git a/mm/memory.c b/mm/memory.c > index c125c4969913..aae53fde13d9 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4622,6 +4622,7 @@ static vm_fault_t __handle_mm_fault(struct vm_area_struct *vma, > struct vm_fault vmf = { > .vma = vma, > .address = address & PAGE_MASK, > + .real_address = address, > .flags = flags, > .pgoff = linear_page_index(vma, address), > .gfp_mask = __get_fault_gfp_mask(vma), At least mm/hugetlb.c:hugetlb_handle_userfault() also initializes vmf and calls handle_userfault() so it should initialize real_address? Also there are a few other places that initialize vmf but they use vmf only for swapin so probably they don't reach to userfault code. Still it seems a bit fragile to not initialize real_address there? Not strong opinion there... Ideally we would not misuse vmf in those places but that's a larger cleanup. Honza -- Jan Kara SUSE Labs, CR