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 X-Spam-Level: X-Spam-Status: No, score=-11.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31DE6C43461 for ; Tue, 27 Apr 2021 15:54:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD75261289 for ; Tue, 27 Apr 2021 15:54:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD75261289 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BD07E6B006C; Tue, 27 Apr 2021 11:54:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B7FA36B006E; Tue, 27 Apr 2021 11:54:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D2A86B0070; Tue, 27 Apr 2021 11:54:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 804076B006C for ; Tue, 27 Apr 2021 11:54:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 39F87181AF5C1 for ; Tue, 27 Apr 2021 15:54:23 +0000 (UTC) X-FDA: 78078594006.09.82960F3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id D60BCC0007C6 for ; Tue, 27 Apr 2021 15:54:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619538862; 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=F2EAyRlyPf7sFuC/hgHV65Ah6f40dk7Oz+0C6LVfX60=; b=eZQZb+nITq/NnD0fHVpiEFL8mXYbIxiYAZPUGqUD2QyeUuYpJzDzK9T1q2MkSZD5jkhpba yM2iSH2jtRnuj9i1WWjpFk2aSF9E0yUgrRJhboavxm8J3tAvA/RQjJ3Si0d6COWzpol12x mnPHC1oLP1CeG35uqL88ZLEPwOoUW4M= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-318-mREjCCLVOJOG0IU5AC8Ogg-1; Tue, 27 Apr 2021 11:54:17 -0400 X-MC-Unique: mREjCCLVOJOG0IU5AC8Ogg-1 Received: by mail-qk1-f199.google.com with SMTP id k12-20020a05620a0b8cb02902e028cc62baso23214697qkh.17 for ; Tue, 27 Apr 2021 08:54:17 -0700 (PDT) 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=F2EAyRlyPf7sFuC/hgHV65Ah6f40dk7Oz+0C6LVfX60=; b=sXs7MDshnJuZqA6MFWv/K2PxmIuNGVUuUbW5I793cUQubFFMMqgjJuwzSkMzuPiBxM 72sHLd4aMw+w+8JKDHHryeWRQBlj5smkf4GYmtIUNIts1fKrDYcrWROvM+lEO/s2JBVd FCcV0hPZ8SgNCf7hlqRjJ6ZGC7bUEmfvScubqrGK2dC0l+VXdJf1bcFy7/3AeRhk0hrl W5SIJ2exGz2Ai4TQ33L/BDHop+IGqeELdatAOdjBk0MQVzHtiqupvSXN0d7V7v82MvUA AieNviMPkNoQUQGHIXipyaJaQZlvbqnHekoU4/QGnocsb+rEG4tPxxtZTmOGuQNUfd2k aYnw== X-Gm-Message-State: AOAM533wZFOsjWa/L6hfGErUZ06/Gh9fqM2C76YlxxLoNQGCnUQ9bWC/ sHqhO+8m/I0AIzgQsKmffE0trq3xpAqgiv2cDxidsuT0ilCg8vxiqY+totJTwAGMBFuhDU/YYXk kcsgsV8Och2w= X-Received: by 2002:ac8:4455:: with SMTP id m21mr11149107qtn.192.1619538857302; Tue, 27 Apr 2021 08:54:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjPXLMKWECur9Mqt8jATos9gtIg5JYkYXdpYunNG2EodbYnflzFS1Fc8CUzF2HNgSB2Ko5hg== X-Received: by 2002:ac8:4455:: with SMTP id m21mr11149060qtn.192.1619538857004; Tue, 27 Apr 2021 08:54:17 -0700 (PDT) Received: from xz-x1 (bras-base-toroon474qw-grc-77-184-145-104-227.dsl.bell.ca. [184.145.104.227]) by smtp.gmail.com with ESMTPSA id f24sm167754qto.45.2021.04.27.08.54.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Apr 2021 08:54:16 -0700 (PDT) Date: Tue, 27 Apr 2021 11:54:14 -0400 From: Peter Xu To: Hugh Dickins Cc: Axel Rasmussen , Alexander Viro , Andrea Arcangeli , Andrew Morton , Jerome Glisse , Joe Perches , Lokesh Gidra , Mike Kravetz , Mike Rapoport , 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 v4 03/10] userfaultfd/shmem: support UFFDIO_CONTINUE for shmem Message-ID: <20210427155414.GB6820@xz-x1> References: <20210420220804.486803-1-axelrasmussen@google.com> <20210420220804.486803-4-axelrasmussen@google.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Queue-Id: D60BCC0007C6 X-Stat-Signature: 8txedymrwhnhpzq6ex5u4hogpao18w5n X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf06; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=170.10.133.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619538865-407314 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 Mon, Apr 26, 2021 at 07:19:58PM -0700, Hugh Dickins wrote: > On Tue, 20 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 > > If this "03/10" had been numbered 04/10, I would have said > Acked-by: Hugh Dickins > > But I find this new ordering incomprehensible - I'm surprised that it > even builds this way around (if it does): this patch is so much about > what has been enabled in "04/10" (references to UFFDIO_CONTINUE shmem > VMAs etc). > > Does Peter still think this way round is better? If he does, then we > shall have to compromise by asking you just to squash the two together. Hi, Hugh, Axel, I have no strong opinion. To me, UFFDIO_CONTINUE can be introduced earlier like this. As long as we don't enable the feature (which is done in the next patch), no one will be able to call it, then it looks clean. Merging them also looks good to me. Thanks, -- Peter Xu