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 86047C433ED for ; Wed, 19 May 2021 14:09:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 634AE6135A for ; Wed, 19 May 2021 14:09:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347085AbhESOK7 (ORCPT ); Wed, 19 May 2021 10:10:59 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:40390 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347019AbhESOK6 (ORCPT ); Wed, 19 May 2021 10:10:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1621433378; 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=UTUq2TTGyY9dE8Olt7QpXIu8mXkiPNygQpj9xSUaFHg/0+askFMEtXF/IGbj0QlitT8YAK kmfjFtvNbw9PYGwmytXHw+ZGCt+LW2Q5zJV+4+CbWuNbYsvebKTP0LlWWV+hjnwxLmeZia /ZX/ZMgArvz8UwNn5cVIBdAtoFhQrqk= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-72-Svvzq1hxP-e7a2GMMIFrNw-1; Wed, 19 May 2021 10:09:35 -0400 X-MC-Unique: Svvzq1hxP-e7a2GMMIFrNw-1 Received: by mail-qv1-f70.google.com with SMTP id l61-20020a0c84430000b02901a9a7e363edso10381020qva.16 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=H0TG3vDHkORTRS4dpx19J1NyUmNrD1KTT04qhWZBuywj4YCpYE129TBxWSM9aABAPy cDY1TwuYibvlmIE89+bQ7GjFbI8qgUXTmivXHEISRH61SSZud68gBC8TWAECcxyh+JJI fuTaOUZ6RbbgBkUoSZNfOMqFELtwo82a5T3PWf1jxQ2RiwVjbt2ZpElz2eIKc/cKgtTL dFXB9m62slnQM3yWVUG4gxAy81sEKh/qX5cs3y0CWV1krL4/CSD4k82zg6k6zVCyth5m ZZRQu87eWQy5gdsb40LVYoiyzF5wBerD1VxgX5NTrYFEMNlNFHOqhxHwAum/PqHC/fTv qMwg== X-Gm-Message-State: AOAM533Y1BG+NXX22Wq1tk2SVhHOByUe5+Tg0cB2sivI1JbW3dPrTboq tnQI+WTFfZTWRhe8RJbpSxSG2xUImDjAT+dvMErAkFcXjeIEq/idiQKUlTX7UnO5417YIGWl9jV YWJEu4zZ0HdwennoFBhPT X-Received: by 2002:a05:622a:413:: with SMTP id n19mr11309598qtx.238.1621433375265; 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210519132842.GJ1002214@nvidia.com> Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org 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 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 EFC22C433B4 for ; Wed, 19 May 2021 16:29:20 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0D1D461007 for ; Wed, 19 May 2021 16:29:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D1D461007 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=nouveau-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8A6DC6EE2D; Wed, 19 May 2021 16:29:12 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 862936EDC3 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=1621433377; 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=KFmiMj3s2us43/++cpPNGprz9FWDrJ3XOUFDYYYXGhqmakgiZ/af8CvyAPfS2kBeoNwt9l uPLmAoOb9RYF4gt6p5J4+UBUHQn+V6bSki4q/yB2cDS9v9MsxkV+4jW+9hH0GnZZ7GHvHC 28jjjOWVpS4imP0Qszj0PUjZK5b7Kw4= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-221-bCZDavjrPluxySxUG3PZBw-1; Wed, 19 May 2021 10:09:35 -0400 X-MC-Unique: bCZDavjrPluxySxUG3PZBw-1 Received: by mail-qv1-f69.google.com with SMTP id w4-20020a0c8e440000b02901f0640ffdafso5553297qvb.13 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=TMRL0/AB0jkdG5G3dD6gqgnfSNT3B3O4QAamkcnj+aDtkZLKM4cPMj0EzItiW7LVHM AtyXSgbrCWq0iCjvN/1+OacJ5Si7fDS8DE/I5j5DVqwL/E85xmfmeJjV5D3JIGdEyvuq vD+/dgBoNsooVM0MldhK4kaRbzGdUegRcmIG9rtSBjMUXAKAgbg/MG75mBammraHU5bA N4GwnSJshRDZXBc/ZGJJa2s5N7fEJGdIvUEc/v7WGfQmM5jDa4LkCKOlDi1B/QNGQ6nR HezjydCCSqlwl3Wwe4p26YlMQPJNJYrnXYOHavfUDiIKSkMwsAQaMkoC5cgWdR1PDZ8T gqQA== X-Gm-Message-State: AOAM53210kQOrFz0WbkAltL47+MZvCaMr4MEHUSLqY5pKdD5hqFVW8Wj BucTKlad17AGfW1FUMJZ/o5EEKpoaXIKoJ74qVKvZerUWslne6u4W9VBG+xtuoMcHKt6kbZDobk NVDX6OHlymZvmnG2/tBeVpswCaQ== X-Received: by 2002:a05:622a:413:: with SMTP id n19mr11309608qtx.238.1621433375268; 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 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> 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-Disposition: inline X-Mailman-Approved-At: Wed, 19 May 2021 16:29:11 +0000 Subject: Re: [Nouveau] [PATCH v8 5/8] mm: Device exclusive memory access X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rcampbell@nvidia.com, willy@infradead.org, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, bsingharora@gmail.com, Alistair Popple , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, hch@infradead.org, linux-mm@kvack.org, bskeggs@redhat.com, daniel@ffwll.ch, akpm@linux-foundation.org, Christoph Hellwig Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" 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 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 7BFEFC433ED for ; Wed, 19 May 2021 14:09:43 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 449C26135F for ; Wed, 19 May 2021 14:09:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 449C26135F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7C1D36EDC8; Wed, 19 May 2021 14:09:42 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6A42C6EDC3 for ; Wed, 19 May 2021 14:09:40 +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-25-Uz0ecBNnOz-Z9ndqTfRe7g-1; Wed, 19 May 2021 10:09:35 -0400 X-MC-Unique: Uz0ecBNnOz-Z9ndqTfRe7g-1 Received: by mail-qv1-f71.google.com with SMTP id bc3-20020ad456830000b02901f47dbd7ef6so474769qvb.6 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=cibNHZ0nXgNEQ7qG2XaYnObPbgHpl64LY8Q6D7sZ8sEn7+IC9SAD9YScTWw46yHJgf /WtK/5BcBL1Dkh7WeDhkDeHRHBwwURXoP0gdFAotctn73VuG7+VkiYDcRerrliJAqJj5 PoG3YK4gIym+bI+AqR5vyobU6pMooDaVX0a8NvdnoAGDh9BCVlL391faAXaqxo+ilYfR 9RCsDQYXckBM8cEls/A1kxyEAnSmsrm5Ooh0DOu/MiCRnaM0fczO0EkHYZRO0Ehx0zYE +D62cr4EkSqDlp/bZ8931I/PzefkM4DaSJkcBKh/wiCkCmMIbKu9inu5XIQ75t9drOIh Mx9A== X-Gm-Message-State: AOAM5308xMasfh+ijEISBRipHrStIaSetehTLNFtoNVqXTNip9hzH/LV 19nATapPll9QZyGTF4+nx7ePBl0bDKao5avd7KVH5itaEm3fy/uT6IhKUFXy3eIkwM7B6iagsap DOGVZJs8gV8mgDrnho8SF12ey/1J6 X-Received: by 2002:a05:622a:413:: with SMTP id n19mr11309606qtx.238.1621433375268; 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 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> 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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: rcampbell@nvidia.com, willy@infradead.org, linux-doc@vger.kernel.org, nouveau@lists.freedesktop.org, bsingharora@gmail.com, Alistair Popple , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, hch@infradead.org, linux-mm@kvack.org, jglisse@redhat.com, bskeggs@redhat.com, jhubbard@nvidia.com, akpm@linux-foundation.org, Christoph Hellwig Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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