Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp4958058pxy; Tue, 27 Apr 2021 17:04:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyvDAhmiwSED91s5tqciTGQLHjNpUU2rfz3EOObG57lTMgp+KcXC8cDOTto7D7F4ZrVuX10 X-Received: by 2002:a17:90b:4b86:: with SMTP id lr6mr29955465pjb.77.1619568291900; Tue, 27 Apr 2021 17:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619568291; cv=none; d=google.com; s=arc-20160816; b=xqb+shl/8nMYXgECwKbzAgNpwStQQVMRNIcdNoZD183/qM2TwC1UTvEp8CxwUeNKUK uMToDMpJnbM0hLUtfUaAfMC0HtoNYzAOhelMHV6MUNlIGsxOA24cn0N3IB8pJ2zmuaey SLXW2rUTN0j+1zL9Ng3TKDWIhKNa+fAgaNCeEVZza1YBnDOhYfMELPbFh3J4fsRZ+o9X FYLq8YoFtgBvW2cxgTiSF1GqK81909LcZuXdqupkvu+9QReA096QHn93rDu1aMWVkRJH 5OZIGGvRcL/oG/zJAL4MSrDF9969+NCnpSdLwp44VdXo5TVTAyhC68VPWriY5tA1WXGB xJ2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=xacAZXww+/r1bYXmcQWffobgGN8QvzDcUp5VNbqVO2g=; b=TwZNozYKxuM5uGVL9tVwpzMDfSTSaEklI95AyPxoG4S47ddHHFt3BJ/Qsb4vg/HYMV AQvhv1BoZlvo+DTQgLziZoDpPQxhPfObGHHiQf0gdQGadg0cCjy/kiN/rGExVrEEHNMb +z5xudj3Fd4IQ/6oyOg9kRdW+Qvb+kUcCbPjBsZDx2tcfIceqtoaq7orVW5odjmarjZU 36mgFPanV5vcLifH7h2sC9TdjlUmFPePNYJ814YqaVcaziRMnjo6UkPBxPKiYBfjOpuU yWm1XOmfctr+o4RLzeAajrok95GRcDjO81G5AlOV0pupK5w+4k8goCbs92xuI2xpSJMk LZ9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h59I82pB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v23si1646283plg.323.2021.04.27.17.04.23; Tue, 27 Apr 2021 17:04:51 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=h59I82pB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237984AbhD1AEF (ORCPT + 99 others); Tue, 27 Apr 2021 20:04:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230368AbhD1AEF (ORCPT ); Tue, 27 Apr 2021 20:04:05 -0400 Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DAAAC061574 for ; Tue, 27 Apr 2021 17:03:21 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id z20-20020a0568301294b02902a52ecbaf18so4554018otp.8 for ; Tue, 27 Apr 2021 17:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=xacAZXww+/r1bYXmcQWffobgGN8QvzDcUp5VNbqVO2g=; b=h59I82pBb9CSjo53IXp5WlilB8BELyUyymcAkd7h7D/t8//pyn5b1QYqX/2KNcMMte AArc97JJ6OtqU61vD0xKuqULCy4SntW4x1jnWa8jX1jAdd7z1a0wvl+1c43Ax+tPfgvp GySDj+7ZVf0MRQwIc8xOBSN7GWeeDZr51l4ZLBjUw8ISAfdOPsh1RsUYMHRu3emXp16S Gzu3w9xqBLGrm+yukJsGw2+ETqrSRIQBfjrA3OwvGoxyReveyWDafwio18B05Vtjf3Yz LMxBS6XZ5bGhvFIKOJzoz3O2FEEUEmh7DDllLTRdPVLhtX+lZb+Nson3KQz/GNJPDKW9 PIaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=xacAZXww+/r1bYXmcQWffobgGN8QvzDcUp5VNbqVO2g=; b=t1obmGO48mfKgCeGAT5k93V5gcAtoWs19lL6jTHQvRf8rdvVEHzFq7wnlzJd4xvWj7 cYi+RoYXcwjJ3YP0AF/189avUivwA0cM39r+kPnWkLI9aFfCgnqzep6QJl8mvZg7YZPe CE7YSw7RgWq6tBxmy8hoOFGhy5Ltr3bOigB5YsYJgCd+yNtCgxq+DfOxmldV0myK6Cgl pdSVcKNLsrW2+dn9hLn6Ab2vUXUpqDGccXXGxEDwnH6eaeUPFZCijxAqvadAiGPQqoMt 56Lmy1UVWnO/xsAkUht88nizH1W2qqWLLb0J4BVv3hRpuCDNh8UXctZ7ITCFIM3NUXML XwHQ== X-Gm-Message-State: AOAM533c0ZyK5hjUv6t1S8oGYB6Hxh8uZ0grXZaL4XhjR+HRoCjzPsMM ZJBUjbcp8lN4jid5N5RaoVXsVA== X-Received: by 2002:a9d:6c52:: with SMTP id g18mr20760460otq.29.1619568200397; Tue, 27 Apr 2021 17:03:20 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id e12sm324759otq.46.2021.04.27.17.03.18 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 27 Apr 2021 17:03:20 -0700 (PDT) Date: Tue, 27 Apr 2021 17:03:17 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Axel Rasmussen cc: Alexander Viro , Andrea Arcangeli , Andrew Morton , Hugh Dickins , Jerome Glisse , Joe Perches , Lokesh Gidra , Mike Kravetz , Mike Rapoport , Peter Xu , Shaohua Li , Shuah Khan , Stephen Rothwell , Wang Qing , linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Brian Geffon , "Dr . David Alan Gilbert" , Mina Almasry , Oliver Upton Subject: Re: [PATCH v5 04/10] userfaultfd/shmem: support UFFDIO_CONTINUE for shmem In-Reply-To: <20210427225244.4326-5-axelrasmussen@google.com> Message-ID: References: <20210427225244.4326-1-axelrasmussen@google.com> <20210427225244.4326-5-axelrasmussen@google.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 27 Apr 2021, Axel Rasmussen wrote: > With this change, userspace can resolve a minor fault within a > shmem-backed area with a UFFDIO_CONTINUE ioctl. The semantics for this > match those for hugetlbfs - we look up the existing page in the page > cache, and install a PTE for it. > > This commit introduces a new helper: mcopy_atomic_install_pte. > > Why handle UFFDIO_CONTINUE for shmem in mm/userfaultfd.c, instead of in > shmem.c? The existing userfault implementation only relies on shmem.c > for VM_SHARED VMAs. However, minor fault handling / CONTINUE work just > fine for !VM_SHARED VMAs as well. We'd prefer to handle CONTINUE for > shmem in one place, regardless of shared/private (to reduce code > duplication). > > Why add a new mcopy_atomic_install_pte helper? A problem we have with > continue is that shmem_mcopy_atomic_pte() and mcopy_atomic_pte() are > *close* to what we want, but not exactly. We do want to setup the PTEs > in a CONTINUE operation, but we don't want to e.g. allocate a new page, > charge it (e.g. to the shmem inode), manipulate various flags, etc. Also > we have the problem stated above: shmem_mcopy_atomic_pte() and > mcopy_atomic_pte() both handle one-half of the problem (shared / > private) continue cares about. So, introduce mcontinue_atomic_pte(), to > handle all of the shmem continue cases. Introduce the helper so it > doesn't duplicate code with mcopy_atomic_pte(). > > In a future commit, shmem_mcopy_atomic_pte() will also be modified to > use this new helper. However, since this is a bigger refactor, it seems > most clear to do it as a separate change. > > Signed-off-by: Axel Rasmussen Acked-by: Hugh Dickins > --- > mm/userfaultfd.c | 172 ++++++++++++++++++++++++++++++++++------------- > 1 file changed, 127 insertions(+), 45 deletions(-)