Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp639605pxu; Thu, 7 Jan 2021 14:16:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJx4RU33PLIYVx2+CMRH2213TPttTMyV8qz+9l8mG96rQ7i/ADeDgRse/ye3nrVhZmHTyYfN X-Received: by 2002:a17:907:6e6:: with SMTP id yh6mr680357ejb.512.1610057818282; Thu, 07 Jan 2021 14:16:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610057818; cv=none; d=google.com; s=arc-20160816; b=U8R3SgkIfWeQMlhIVg2UP9RCGlaRyJwKdcV9PO3lk/34UCj0dLk+4TNiaGIUtHA6Z9 403sYefsLF2CnmCan+xFwHOfW6oYmG54frqzE+T8vp2eoRM3C/sCPa9g/Fjus6Knqnjp myeD21ipOf8Ye4oBteqx9q8WHxuUSUX9wxabLulmMyGbcfBpb5hD94y+tHU4cwGbGqc8 5T8NXfEcqOiKMKVl9wgGek4GgUedJiU0JKXKg0joj7wfeyyZiLOKpzaG4DD37u44lLHr JFcb+zeRcgCuSOuA6bvsWzOWmUV6EFOgbAN7wVtrEfi/wYMy2PHKGUy7+1Hjfgz0iIUs 3kzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:dkim-signature:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=mvMt3QV0kxLxxUJ0iTscamiEGgHeUeuZhDh1c1xneBs=; b=ePc2dMfq2M/9RzvhYsESwsw7yEzdPJXyxHhnIZ4Xa3aQ4TClW3TAuYeIFLGSOkNK4w 4NDve5MNTr3xFHud0HEjFc/BwnFqX+K7wIg9Ps6NU3UY0hECx9gr81wj1Ob2t9kp+q8X pUdcsTuQSIqJbSN3LdF9J/ePmlTfU3ABz65SouMSNTZoFcBn8vOMmwYsiwkgwmGjdtOK 9ex7vWHmbZ8lxHtCo78xqpCMILK3ZxaV+QgYb9/IiLqkDVos7X1Ufe2tzpCdpgynoDNE +HBpQSaO7HhW1EghHAj0VPE1OqZtYxDLFHGXXXC8wb8u8DsClHhFbqSOjtK6w8WsDIcd gYcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=afxZ3z0k; 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=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ck16si2879256edb.36.2021.01.07.14.16.34; Thu, 07 Jan 2021 14:16:58 -0800 (PST) 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=@nvidia.com header.s=n1 header.b=afxZ3z0k; 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=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727494AbhAGWPa (ORCPT + 99 others); Thu, 7 Jan 2021 17:15:30 -0500 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:19365 "EHLO hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726646AbhAGWP3 (ORCPT ); Thu, 7 Jan 2021 17:15:29 -0500 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 07 Jan 2021 14:14:49 -0800 Received: from [10.2.53.45] (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Jan 2021 22:14:46 +0000 Subject: Re: [PATCH 2/2] mm: soft_dirty: userfaultfd: introduce wrprotect_tlb_flush_pending To: Linus Torvalds CC: Andrea Arcangeli , Linux-MM , Linux Kernel Mailing List , Yu Zhao , Andy Lutomirski , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , "Minchan Kim" , Will Deacon , Peter Zijlstra , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oleg Nesterov , Jann Horn , Kees Cook , Leon Romanovsky , Jason Gunthorpe , Jan Kara , Kirill Tkhai References: <20210107200402.31095-1-aarcange@redhat.com> <20210107200402.31095-3-aarcange@redhat.com> <4100a6f5-ab0b-f7e5-962f-ea1dbcb1e47e@nvidia.com> From: John Hubbard Message-ID: <394e17bc-8bed-4d17-5dba-9ab8052c8bea@nvidia.com> Date: Thu, 7 Jan 2021 14:14:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Thunderbird/84.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610057689; bh=mvMt3QV0kxLxxUJ0iTscamiEGgHeUeuZhDh1c1xneBs=; h=Subject:To:CC:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:X-Originating-IP:X-ClientProxiedBy; b=afxZ3z0kPyVRwdvpJCH3q64AwBm5K/Ggg+Hzr/lRkexTGNAaJrDyc06ZCeMZoYCOj CjvOZK3MLvTKT6Pwc9p5IByX2pxAhyCBvw+/NG1cf+hmQU41UUJ3bJe1xHuwoDz0lN ReYmK9FZmAHhg7vEl1INn854JWe2cWWhLEPpINXbAjdihhQhVZWFk152WjEhPNIa/j Q2ADPLf8eomtRQnfIL7yR39+zoAnqsx4dYOu8KtncCV6afFKkHvcitdrx18b5O5GT7 92PD4bN/G32nzm3kCGe2CPWCJF/Cycm9hG11uANRc+SOjv8YHz0NSbjT3wV5iw4MrU qe2bO9eFfEAGg== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/7/21 2:00 PM, Linus Torvalds wrote: > On Thu, Jan 7, 2021 at 1:53 PM John Hubbard wrote: >> >>> >>> Now, I do agree that from a QoI standpoint, it would be really lovely >>> if we actually enforced it. I'm not entirely sure we can, but maybe it >>> would be reasonable to use that >>> >>> mm->has_pinned && page_maybe_dma_pinned(page) >>> >>> at least as the beginning of a heuristic. >>> >>> In fact, I do think that "page_maybe_dma_pinned()" could possibly be >>> made stronger than it is. Because at *THAT* point, we might say "we >> >> What exactly did you have in mind, to make it stronger? I think the >> answer is in this email but I don't quite see it yet... > > Literally just adding a " && page_mapcount(page) == 1" in there > (probably best done inside page_maybe_dma_pinned() itself) Well, that means that pages that are used for pinned DMA like this, can not be shared with other processes. Is that an acceptable limitation for the RDMA users? It seems a bit constraining, at first glance anyway. > >> Direct IO pins, on the other hand, are more transient. We can probably live >> without tagging Direct IO pages as FOLL_PIN. I think. > > Yes. I think direct-IO writes should be able to just do a transient > GUP, and if it causes a COW fault that isn't coherent, that's the > correct semantics, I think (ie the direct-IO will see the original > data, the COW faulter will get it's own private copy to make changes > to). > > I think pinning should be primarily limited to things that _require_ > coherency (ie you pin because you're going to do some active two-way > communication using that page) > > Does that match your thinking? > Yes, perfectly. I'm going to update Documentation/core-api/pin_user_pages.rst accordingly, once the dust settles on these discussions. thanks, -- John Hubbard NVIDIA