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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 005E8C433ED for ; Wed, 31 Mar 2021 12:54:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 66EFF61962 for ; Wed, 31 Mar 2021 12:54:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 66EFF61962 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 C69F36B007E; Wed, 31 Mar 2021 08:54:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C19F16B0081; Wed, 31 Mar 2021 08:54:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6D026B0082; Wed, 31 Mar 2021 08:54:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0034.hostedemail.com [216.40.44.34]) by kanga.kvack.org (Postfix) with ESMTP id 8C3D76B007E for ; Wed, 31 Mar 2021 08:54:19 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 399A3181AEF3C for ; Wed, 31 Mar 2021 12:54:19 +0000 (UTC) X-FDA: 77980162638.03.E844E89 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 90E0EA0003A0 for ; Wed, 31 Mar 2021 12:54:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617195258; 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=BLVqguYYRqWS+fkpiZrnYWlDg4Em6ZwexNgxX0lsnu4=; b=UL6EXQdO5g1UYBMM7lvaoctkDlFOu2zb2zs6E9WwVa2h0s1weEr2M/ecowJVK27rsrR3sY Q2vPTEI9vsNzB7qoZ+I3ksY6/JVdeAXj6kAgG+8UuCQc97t4eoA9lA6sY1xUFPYYq8vMPD guz2VM/NKVvU75di/qtsmoMtY/WX4lQ= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-358-vE-Zum86Ni6bG_RNVj9GAg-1; Wed, 31 Mar 2021 08:54:14 -0400 X-MC-Unique: vE-Zum86Ni6bG_RNVj9GAg-1 Received: by mail-qt1-f199.google.com with SMTP id j2so1085087qtv.10 for ; Wed, 31 Mar 2021 05:54:14 -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=BLVqguYYRqWS+fkpiZrnYWlDg4Em6ZwexNgxX0lsnu4=; b=N2K+ZBAdTpB0p3rXETrZWkrJARW8757zrGrDOvF5YgbS8knIqeg5z/SkOtqNOL9gKn +Nqn0hw4rLWXE35t7UsI3o7chUToUhX6naf9oz6c2YY6jLXapOh7NlOMXu+zxpSmB6c+ Un51AE8oqlGaK2Yz3PXUXuEQc+hkPKM1yWD5KBDZWrhvs1ZdoTjwA6y2qNO8y677UMRX ZJEsQ9d3aDr7sCh9kgDiFCREQ7YLOMdGN3DUZEwCtavGRd6H/vr/DE4Mk4SnyUVlNVac WgP+c+kXpmGlUFaz9WxFs6CnK7vIhcpyfH9dA9UvG6JizXIpdhtELs2ExF9Ee6l0STV/ +zhA== X-Gm-Message-State: AOAM531ZN/QZFTx0R1SYDAfoz8YnD63zSUj8/sZYHrvtnCZeo73SzNfo Z26NjXQwR8IuzgvrzpnKRa6d83Opnj+Wn9oE+3cvzVU8Ym/ndUqGPOPw0aZqAezQOcjCeOohFz2 kkuD2YkE+eLc= X-Received: by 2002:a05:622a:48d:: with SMTP id p13mr2279118qtx.21.1617195253823; Wed, 31 Mar 2021 05:54:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyUI7wPo7TLqkGMdpy3kH1M1sXi6ovrIE72FbmoqiknBlD6P60sY1MhBQ3ElvmViqcwOGvUsQ== X-Received: by 2002:a05:622a:48d:: with SMTP id p13mr2279090qtx.21.1617195253556; Wed, 31 Mar 2021 05:54:13 -0700 (PDT) Received: from xz-x1 (bras-base-toroon474qw-grc-82-174-91-135-175.dsl.bell.ca. [174.91.135.175]) by smtp.gmail.com with ESMTPSA id a19sm1330189qkl.126.2021.03.31.05.54.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 31 Mar 2021 05:54:12 -0700 (PDT) Date: Wed, 31 Mar 2021 08:54:09 -0400 From: Peter Xu To: Axel Rasmussen Cc: Alexander Viro , Andrea Arcangeli , Andrew Morton , Hugh Dickins , Jerome Glisse , Joe Perches , Lokesh Gidra , Mike Rapoport , Shaohua Li , Shuah Khan , Stephen Rothwell , Wang Qing , LKML , linux-fsdevel@vger.kernel.org, Linux MM , linux-kselftest@vger.kernel.org, Brian Geffon , Cannon Matthews , "Dr . David Alan Gilbert" , David Rientjes , Michel Lespinasse , Mina Almasry , Oliver Upton Subject: Re: [PATCH v3] userfaultfd/shmem: fix MCOPY_ATOMIC_CONTNUE behavior Message-ID: <20210331125409.GL429942@xz-x1> References: <20210329234131.304999-1-axelrasmussen@google.com> <20210330205519.GK429942@xz-x1> 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-Server: rspam03 X-Rspamd-Queue-Id: 90E0EA0003A0 X-Stat-Signature: n47msg8n4khwaqzdtqn6pajzymjbw9a5 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf24; 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: 1617195257-479104 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: Axel, On Tue, Mar 30, 2021 at 04:30:13PM -0700, Axel Rasmussen wrote: > Yes, a refactor like that is promising. It's hard to say for certain > without actually looking at the result - I'll spend some time tomorrow > on a few options, and send along the cleanest version I come up with. Before you move onto a new version... See this commit: 5b51072e97d5 ("userfaultfd: shmem: allocate anonymous memory for MAP_PRIVATE shmem", 2018-11-30) I found it when I was thinking why not move the whole continue logic directly into mfill_atomic_pte(), if we can have the pte installation helper, because that's all we need. So previously I got the semantics a bit mixed up: for private shmem mappings, UFFDIO_COPY won't fill in page cache at all, but it's all private. We keep the page cache empty even after UFFDIO_COPY for a private mapping. UFFDIO_CONTINUE is slightly different, since we _know_ the page cache is there.. So I'm thinking maybe you need to handle the continue request in mfill_atomic_pte() before the VM_SHARED check so as to cover both cases. -- Peter Xu