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=-6.1 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 DAF3AC43460 for ; Wed, 19 May 2021 14:09:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8C56C611AE for ; Wed, 19 May 2021 14:09:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8C56C611AE 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 ED2616B006E; Wed, 19 May 2021 10:09:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E821D6B0070; Wed, 19 May 2021 10:09:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4A056B0071; Wed, 19 May 2021 10:09:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0171.hostedemail.com [216.40.44.171]) by kanga.kvack.org (Postfix) with ESMTP id A4AF16B006E for ; Wed, 19 May 2021 10:09:40 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 22E08181AF5CC for ; Wed, 19 May 2021 14:09:40 +0000 (UTC) X-FDA: 78158163720.14.E0D187B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id E6F0B8019106 for ; Wed, 19 May 2021 14:09:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621433379; 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=uA5LBQUpQQcpe5I2oDgwRimXB7jI4me/eAnHY5LMMkc=; b=QZoouhKRvFvtERgoGOmJnf9pIblfrwfd2yOU1vG6/wmlQElw362ziYQK7zfrWnvWnss3MK W6/K9zEKeplRIEfB44Q9jdA/iGbzuQSAKE/3+D5Jm98GI3JBIE2FJV7+n8FS/+bLIkALbf 4VP0n0o8wRakA/bt8EIa2OT+LTfK2Mk= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-440-9LhB9cAAPHq8AScoF8u0cg-1; Wed, 19 May 2021 10:09:35 -0400 X-MC-Unique: 9LhB9cAAPHq8AScoF8u0cg-1 Received: by mail-qv1-f71.google.com with SMTP id l19-20020a0ce5130000b02901b6795e3304so10424803qvm.2 for ; Wed, 19 May 2021 07:09:35 -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=uA5LBQUpQQcpe5I2oDgwRimXB7jI4me/eAnHY5LMMkc=; b=FXcnfZ2+H6Eo222NVJpkalIiNRj6eGnyRNqDTctTCkpzkOGuDYu6rDTVa8e8CphWyV bO7fPtJj20rEBEoJ0MTICBEAQ+aPuwb+s8LkVOTiZ0g260N3YRDPRX5NEw0k8/QVPtJR 63n7nHDSGFMscvlqN0YAsmPZQjPNePtVJ11sU2ohh86807BE33g8TiscavkDVjzqHRnX eXqqf75gXSkZTJOiA1D67WGmLobtFWNlQzxnZgVKIBcH4Xq1f8Ph7sOdI37Kxp816vYl 0bAk0bRynlQzsWAPk4t9Ge3DnQXZ5fOCAlTMLrSGJ7AU6UB2TIwaZCCgTi0pJhvGHMFx iwsg== X-Gm-Message-State: AOAM532Ipw3npxyDdM+fnXtFIIBIK3UIXj6oB7WP4rMBtfoOq5TKEmX7 v8ZVXPZjCEexnhzNNDqnkELLtZnzCADierMYbj0vFqJd52UICaC7jGZp8uwSDVpXD1heXR9Y2n1 l0m11m85Xjn0= X-Received: by 2002:a05:622a:413:: with SMTP id n19mr11309603qtx.238.1621433375267; Wed, 19 May 2021 07:09:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfgXghdceBt0pzuJuLcMWZrj1qSDnzHPuTLDIdA4muPS9QaO8qeOo+lEtQMgzjzxGPQ17Ppg== X-Received: by 2002:a05:622a:413:: with SMTP id n19mr11309576qtx.238.1621433375015; Wed, 19 May 2021 07:09:35 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-72-184-145-4-219.dsl.bell.ca. [184.145.4.219]) by smtp.gmail.com with ESMTPSA id c20sm15634299qtm.52.2021.05.19.07.09.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 07:09:34 -0700 (PDT) Date: Wed, 19 May 2021 10:09:33 -0400 From: Peter Xu To: Jason Gunthorpe Cc: Alistair Popple , linux-mm@kvack.org, nouveau@lists.freedesktop.org, bskeggs@redhat.com, akpm@linux-foundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, jhubbard@nvidia.com, rcampbell@nvidia.com, jglisse@redhat.com, hch@infradead.org, daniel@ffwll.ch, willy@infradead.org, bsingharora@gmail.com, Christoph Hellwig Subject: Re: [PATCH v8 5/8] mm: Device exclusive memory access Message-ID: References: <47694715.suB6H4Uo8R@nvdebian> <20210518173334.GE1002214@nvidia.com> <20210518194509.GF1002214@nvidia.com> <20210518230327.GG1002214@nvidia.com> <20210519132842.GJ1002214@nvidia.com> MIME-Version: 1.0 In-Reply-To: <20210519132842.GJ1002214@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QZoouhKR; spf=none (imf08.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: E6F0B8019106 X-Stat-Signature: bn58nzadt56ia8tkptztebyu88phfuc5 X-HE-Tag: 1621433378-184870 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 Wed, May 19, 2021 at 10:28:42AM -0300, Jason Gunthorpe wrote: > On Tue, May 18, 2021 at 07:45:05PM -0400, Peter Xu wrote: > > On Tue, May 18, 2021 at 08:03:27PM -0300, Jason Gunthorpe wrote: > > > Logically during fork all these device exclusive pages should be > > > reverted back to their CPU pages, write protected and the CPU page PTE > > > copied to the fork. > > > > > > We should not copy the device exclusive page PTE to the fork. I think > > > I pointed to this on an earlier rev.. > > > > Agreed. Though please see the question I posted in the other thread: now I am > > not very sure whether we'll be able to mark a page as device exclusive if that > > page has mapcount>1. > > IMHO it is similar to write protect done by filesystems on shared > mappings - all VMAs with a copy of the CPU page have to get switched > to the device exclusive PTE. This is why the rmap stuff is involved in > the migration helpers Right, I think Alistair corrected me there that I missed the early COW happening in GUP. Actually even without that GUP triggering early COW it won't be a problem, because as long as one child mm restored the pte from exclusive to normal (before any further COW happens) device exclusiveness is broken in the mmu notifiers, and after that point all previous-exclusive ptes actually becomes the same as a very normal PageAnon. Then it's very sane to even not have the original page in parent process, because we know each COWed page will contain all the device atomic modifications (so we don't really have the requirement to return the original page to parent). Sorry for the noise. -- Peter Xu