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=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 3E013C433E0 for ; Sat, 16 Jan 2021 03:41:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0783423A34 for ; Sat, 16 Jan 2021 03:41:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726810AbhAPDl2 (ORCPT ); Fri, 15 Jan 2021 22:41:28 -0500 Received: from hqnvemgate24.nvidia.com ([216.228.121.143]:3019 "EHLO hqnvemgate24.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725601AbhAPDl2 (ORCPT ); Fri, 15 Jan 2021 22:41:28 -0500 Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Fri, 15 Jan 2021 19:40:47 -0800 Received: from [10.2.48.179] (172.20.145.6) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 16 Jan 2021 03:40:47 +0000 Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse To: David Hildenbrand , Jason Gunthorpe CC: Andrea Arcangeli , Andrew Morton , , , Yu Zhao , Andy Lutomirski , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra , Linus Torvalds , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , "Oleg Nesterov" , Jann Horn , Kees Cook , Leon Romanovsky , Jan Kara , Kirill Tkhai , Nadav Amit , Jens Axboe References: <20210110004435.26382-1-aarcange@redhat.com> <20210115183721.GG4605@ziepe.ca> From: John Hubbard Message-ID: Date: Fri, 15 Jan 2021 19:40:46 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.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: HQMAIL111.nvidia.com (172.20.187.18) To HQMAIL107.nvidia.com (172.20.187.13) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610768447; bh=8WRo2pSy6GmhiZT69BhPZn1RMDf4lV1wNtgydXKBlEQ=; 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=LqRvAiHwiZoGNsjzttB+2zzVFY2LZDqGPUV4h0dc6gGlfnJsO6Bpnc5d2m9kQMyZY /Gytqa09GBKhM4FoCOcDhlMXzyRL0apx8gdUCF2Woue76BX4BlrTIRSNx/V+9f5+4E bFoAdV0zxcXMMg0w9OegSqghXOn5ik7qwDIFimLlDw3FtjbooqgjUJJIYks+UhEbaN 2Qg9Bh3pWgS875JBk2m9JPmYkpFR2F7BeobTgnB5ACc70m69i/olhPz+YX3sD/111F jiV91bIaDPjKyw4xeirAcUrHElnSslRKQVhqr9nlFHJcWjDP/cUTkdojt+OXTEMgTf Gkp6q7lVcVFCw== Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/15/21 11:46 AM, David Hildenbrand wrote: >>> 7) There is no easy way to detect if a page really was pinned: we might >>> have false positives. Further, there is no way to distinguish if it was >>> pinned with FOLL_WRITE or not (R vs R/W). To perform reliable tracking >>> we most probably would need more counters, which we cannot fit into >>> struct page. (AFAIU, for huge pages it's easier). >> >> I think this is the real issue. We can only store so much information, >> so we have to decide which things work and which things are broken. So >> far someone hasn't presented a way to record everything at least.. > > I do wonder how many (especially long-term) GUP readers/writers we have > to expect, and especially, support for a single base page. Do we have a > rough estimate? > > With RDMA, I would assume we only need a single one (e.g., once RDMA > device; I'm pretty sure I'm wrong, sounds too easy). > With VFIO I guess we need one for each VFIO container (~ in the worst > case one for each passthrough device). > With direct I/O, vmsplice and other GUP users ?? No idea. > > If we could somehow put a limit on the #GUP we support, and fail further > GUP (e.g., -EAGAIN?) once a limit is reached, we could partition the > refcount into something like (assume max #15 GUP READ and #15 GUP R/W, > which is most probably a horribly bad choice) > > [ GUP READ ][ GUP R/W ] [ ordinary ] > 31 ... 28 27 ... 24 23 .... 0 > > But due to saturate handling in "ordinary", we would lose further 2 bits > (AFAIU), leaving us "only" 22 bits for "ordinary". Now, I have no idea > how many bits we actually need in practice. > > Maybe we need less for GUP READ, because most users want GUP R/W? No idea. > > Just wild ideas. Most probably that has already been discussed, and most > probably people figured that it's impossible :) > I proposed this exact idea a few days ago [1]. It's remarkable that we both picked nearly identical values for the layout! :) But as the responses show, security problems prevent pursuing that approach. [1] https://lore.kernel.org/r/45806a5a-65c2-67ce-fc92-dc8c2144d766@nvidia.com thanks, -- John Hubbard NVIDIA