Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp477746pxb; Fri, 15 Jan 2021 19:42:43 -0800 (PST) X-Google-Smtp-Source: ABdhPJwOwDov4YmxyVcgzQ8UFcc783VJ19bMGzzjq74kXPAZXK/Ptpt0FMGvmqNXFjMAK8snPNPj X-Received: by 2002:a17:906:3999:: with SMTP id h25mr11205076eje.146.1610768563681; Fri, 15 Jan 2021 19:42:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610768563; cv=none; d=google.com; s=arc-20160816; b=tTMMVVGLm14d7td3E8gXQErcAl9a0TJOdqIf3tvETJm3FxQXApjzptqq4VuSvGxJut 0PO76fB0eT/AQcR1mcwKG4s720BG/Z/TMLHTb6GDY+/i0O/ard/sS10/IDn4E+Izbai7 ZsnI0+zFE/s+zbo2xSU7sqC0ZOXvfltjl5P9/aUyLTDHo1YAGQ1YCU1QUAI2cjqL/A0N I/zSh2KNq4PLW+GowpCzDJEIBBOTaG+0PX1+DQ5hMRmlBnzN51RKVQsBhGjv0dPbEWYi FF474yIDdCMhR1eDsLnbELN1+oBiZZ8ZqsfOASWZs6O08yM2uwVRkOtcOs09DT39Cc9G 836w== 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=8WRo2pSy6GmhiZT69BhPZn1RMDf4lV1wNtgydXKBlEQ=; b=M1eKcHDFyYhwh79rpWaVOsGCrSDbe21A49qx5OKX1L18nhAqtnMhWjltbcpysuQlen AhviE6R6CYuxzUrTXuXwbtAjzbI8qoysdC0RASuho6884YfytCga5t2uBJ8vcgTcR28N 66X7q6mKFJZPDQZkHMCGGN1Otmf1Kju8B/vQXDzBlYq5GnLIrcCtEsr0t7fuU6ZysT5N rB5csgt+pWiumQ1rcIhS2mH16T3rYSEAZ+CuJ3Bd5NSucdpHN2m3DaWDP/4KVO2R1iB2 1sXMbCX+bLbGYisey3nZ/oxo8r1I1E6SgF0VUSM6fpLuRl0Sa/FTn3tQrp9n5+qCTNrJ upBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nvidia.com header.s=n1 header.b=LqRvAiHw; 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 p26si2668905eji.9.2021.01.15.19.42.20; Fri, 15 Jan 2021 19:42:43 -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=LqRvAiHw; 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 S1726059AbhAPDl2 (ORCPT + 99 others); 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