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.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 2833FC433DB for ; Tue, 12 Jan 2021 17:07:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9C11F2311A for ; Tue, 12 Jan 2021 17:07:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9C11F2311A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1D6DE6B0036; Tue, 12 Jan 2021 12:07:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1AC8E6B005C; Tue, 12 Jan 2021 12:07:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C2106B005D; Tue, 12 Jan 2021 12:07:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id EBA4D6B0036 for ; Tue, 12 Jan 2021 12:07:48 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B6864180AD81F for ; Tue, 12 Jan 2021 17:07:48 +0000 (UTC) X-FDA: 77697755016.06.table86_4d14e2427517 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 8E3571004C1C0 for ; Tue, 12 Jan 2021 17:07:48 +0000 (UTC) X-HE-Tag: table86_4d14e2427517 X-Filterd-Recvd-Size: 5788 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 17:07:47 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id A438E23131 for ; Tue, 12 Jan 2021 17:07:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610471266; bh=cvSSa71LyJluu9Pmxtib+8PkanVmQCGP38gGA91zZLo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aiX6W+2hh9vDBoB5yv2VVNmnSpj5y6boU05JLBlRKrkF6ssO1umskBbq9qpjMFke7 DfaIo30hZbYD26zXLgy0bUfbG7lGPEhk/WKRlS7KnJ/WY8cXIiOHa8UvajWoVj1lJ/ b/ZibR6VJzQ7PgQfiTRZs2C9vHeXYEKiSnEVGfoOdJHfjLVaXxeWScOZB78JkKE7YF /TYMBS6N+gUlsmY5LW/jZq7grlkjntd0SeaTJd0vpJ3d9M3GuZa1NR3IFkhg6W5F/J tyQpOIL1gfwdQIRnbA6Uq3+sqDvYc+3BIb34M/dOQ2JHItgbGGAE4zVNqUROb1Fi4j xI1wJKljfY3VQ== Received: by mail-ed1-f47.google.com with SMTP id b2so3147933edm.3 for ; Tue, 12 Jan 2021 09:07:46 -0800 (PST) X-Gm-Message-State: AOAM531yuJVWlCj96HXp3KISoESfDru3cD8MrMpPLsC7aqxdsmFHCKzh z3vHsA+9UfRD0ZlVoLY53iNb+Jr+RsWaLffzH9wpgg== X-Google-Smtp-Source: ABdhPJzR3berhPHmwdu4k3CI9o5QDPNM8DlEFu4t/iWEZD4mSxM9oS5q3rpkf6x6Hf+3Dgdkqu5GN94T109tKPuYAW0= X-Received: by 2002:aa7:c3cd:: with SMTP id l13mr91352edr.97.1610471265004; Tue, 12 Jan 2021 09:07:45 -0800 (PST) MIME-Version: 1.0 References: <20210110004435.26382-1-aarcange@redhat.com> <45806a5a-65c2-67ce-fc92-dc8c2144d766@nvidia.com> In-Reply-To: From: Andy Lutomirski Date: Tue, 12 Jan 2021 09:07:31 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse 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 Content-Type: text/plain; charset="UTF-8" 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 2:18 PM Linus Torvalds wrote: > > On Mon, Jan 11, 2021 at 11:19 AM Linus Torvalds > wrote: > 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. > > What we could do is just make a few clear rules explicit (most of > which we already basically hold to). Starting from that basic > > (a) Anonymous pages are made writable (ie COW) only when they have a > page_count() of 1 Seems reasonable to me. > > That very simple rule then automatically results in the corollary > > (b) a writable page in a COW mapping always starts out reachable > _only_ from the page tables Seems reasonable. I guess that if the COW is triggered by GUP, then it starts out reachable only from the page tables but then because reachable through GUP very soon thereafter. > > and now we could have a couple of really simple new rules: > > (c) we never ever make a writable page in a COW mapping read-only > _unless_ it has a page_count() of 1 I don't love this. Having mprotect() fail in a multithreaded process because another thread happens to be doing a short-lived IO seems like it may result in annoying intermittent bugs. As I understand it, the issue is that the way we determine that we need to COW a COWable page is that we see that it's read-only. It would be nice if we could separately track "the VMA allows writes" and "this PTE points to a page that is private to the owning VMA", but maybe there's no bit available for the latter other than looking at RO vs RW directly. > > (d) we never create a swap cache page out of a writable COW mapping page > > Now, if you combine these rules, the whole need for the > GUP_PIN_COUNTING_BIAS basically goes away. > > Why? Because we know that the _only_ thing that can elevate the > refcount of a writable COW page is GUP - we'll just make sure nothing > else touches it. How common is !FOLL_WRITE GUP? We could potentially say that a short-term !FOLL_WRITE GUP is permitted on an RO COW page and that a subsequent COW on the page will wait for the GUP to go away. This might be too big a can of worms for the benefit it would provide, though. --Andy