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.6 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 22012C433DB for ; Tue, 12 Jan 2021 23:51:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A7B023130 for ; Tue, 12 Jan 2021 23:51:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A7B023130 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 248D46B0117; Tue, 12 Jan 2021 18:51:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D23C6B0126; Tue, 12 Jan 2021 18:51:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C1886B0127; Tue, 12 Jan 2021 18:51:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0067.hostedemail.com [216.40.44.67]) by kanga.kvack.org (Postfix) with ESMTP id E79756B0117 for ; Tue, 12 Jan 2021 18:51:25 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id AC930180AD822 for ; Tue, 12 Jan 2021 23:51:25 +0000 (UTC) X-FDA: 77698772130.30.fork91_2b0766227519 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 74EFB180B3AB8 for ; Tue, 12 Jan 2021 23:51:25 +0000 (UTC) X-HE-Tag: fork91_2b0766227519 X-Filterd-Recvd-Size: 6144 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 23:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610495484; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PxeFnrXFjCMeKRsHViqPHhs/5hTEiB1hQEf1cG4ANpU=; b=KAHRcWiiuvNCIF4/x6JI4Q6UVoyONqXC8mpN2ILeiO0XeTzK741BBnRPgQud1kqi1dBDBg TpzUkwVPrMk4l2hPyhFAX5jEzAR7gpMUwVg4pvpXwMv+cImpFF+MPCNr8tgze1S95jBtPy mL+QE+kPpl6cjozsQzeSSbjWLjkJSM8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-89-rYGW17kXMMe_7ukUMMYRzg-1; Tue, 12 Jan 2021 18:51:20 -0500 X-MC-Unique: rYGW17kXMMe_7ukUMMYRzg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5669E1014E75; Tue, 12 Jan 2021 23:51:16 +0000 (UTC) Received: from redhat.com (ovpn-112-31.rdu2.redhat.com [10.10.112.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9943A13470; Tue, 12 Jan 2021 23:51:06 +0000 (UTC) Date: Tue, 12 Jan 2021 18:51:04 -0500 From: Jerome Glisse To: Linus Torvalds Cc: John Hubbard , Andrea Arcangeli , Andrew Morton , 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 , Nadav Amit , Jens Axboe Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse Message-ID: <20210112235104.GA490399@redhat.com> References: <20210110004435.26382-1-aarcange@redhat.com> <45806a5a-65c2-67ce-fc92-dc8c2144d766@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Content-Transfer-Encoding: quoted-printable 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 Mon, Jan 11, 2021 at 02:18:13PM -0800, Linus Torvalds wrote: > On Mon, Jan 11, 2021 at 11:19 AM Linus Torvalds > wrote: > > > > On Sun, Jan 10, 2021 at 11:27 PM John Hubbard w= rote: > > > IMHO, a lot of the bits in page _refcount are still being wasted (e= ven > > > after GUP_PIN_COUNTING_BIAS overloading), because it's unlikely tha= t > > > there are many callers of gup/pup per page. > > > > It may be unlikely under real loads. > > > > But we've actually had overflow issues on this because rather than > > real loads you can do attack loads (ie "lots of processes, lots of > > pipe file descriptors, lots of vmsplice() operations on the same > > page". > > > > We had to literally add that conditional "try_get_page()" that > > protects against overflow.. >=20 > Actually, what I think might be a better model is to actually > strengthen the rules even more, and get rid of GUP_PIN_COUNTING_BIAS > entirely. >=20 > What we could do is just make a few clear rules explicit (most of > which we already basically hold to). Starting from that basic >=20 > (a) Anonymous pages are made writable (ie COW) only when they have a > page_count() of 1 >=20 > That very simple rule then automatically results in the corollary >=20 > (b) a writable page in a COW mapping always starts out reachable > _only_ from the page tables >=20 > and now we could have a couple of really simple new rules: >=20 > (c) we never ever make a writable page in a COW mapping read-only > _unless_ it has a page_count() of 1 This breaks mprotect(R_ONLY) i do not think we want to do that. This might break security scheme for user space application which expect mprotect to make CPU mapping reads only. Maybe an alternative would be to copy page on mprotect for pages that do not have a page_count of 1 ? But that makes me uneasy toward short lived GUP (direct IO racing with a mprotect or maybe simply even page migration) versus unbound one (like RDMA). Also I want to make sure i properly understand what happens on fork() on a COW mapping for a page that has a page_count > 1 ? We copy the page instead of write protecting the page ? I believe better here would be to protect the page on the CPU but forbid child to reuse the page ie if the child ever inherit the page (parent unmapped the page for instance) it will have to make a copy and the GUP reference (taken before the fork) might linger on a page that is no longer associated with any VM. This way we keep fast fork. J=E9r=F4me