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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 08222C433E0 for ; Mon, 11 Jan 2021 22:25:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7C84C22D03 for ; Mon, 11 Jan 2021 22:25:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7C84C22D03 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9F49A8D005C; Mon, 11 Jan 2021 17:25:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A23B8D0051; Mon, 11 Jan 2021 17:25:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81D958D005C; Mon, 11 Jan 2021 17:25:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id 682098D0051 for ; Mon, 11 Jan 2021 17:25:36 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 33CE71EF1 for ; Mon, 11 Jan 2021 22:25:36 +0000 (UTC) X-FDA: 77694927072.09.idea04_1a0aaec27510 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 19AC0180AD807 for ; Mon, 11 Jan 2021 22:25:36 +0000 (UTC) X-HE-Tag: idea04_1a0aaec27510 X-Filterd-Recvd-Size: 7886 Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 22:25:35 +0000 (UTC) Received: by mail-ej1-f45.google.com with SMTP id 6so655361ejz.5 for ; Mon, 11 Jan 2021 14:25:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ZZPmaTfycN5TXyDAk9rKbx2zlys0NKK1SueTrJQDAs=; b=bTIJUzCrdxQk1QHn4BFCFgsZs0eG+pXn3IDdsP8HnnoYfoAHYXfOqNUspdojwx3AAM Uw8dil2edj0p1CvkSRxWuB6HBUUKucloA2hk16Hk6ulj+Q1XTmjpKDHh/lwk8rVxaPrD +OMEk0lSgqDKNSTmwNth7bf5NXzC31UWUSFnE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ZZPmaTfycN5TXyDAk9rKbx2zlys0NKK1SueTrJQDAs=; b=i9DQxKwquNdu7HHySVW1Cq2p39DeSVITdljUoBjS7U/SCy8hq7uOpK76sEdPatC0dF uEcsZBMAffcTJLRsNZJDSi5V7sKLYt6xRkIHjzxPGr152XZXYWXFTaXdgUXR4rLW3jas A6yEwop91X3xPybXTzOY+Wbv2sOaynfPY/mGCzCyhI98WXFhmhOlU6fqolnMUMtaOorJ LGZI26AfJ1sfJOY4xoMUM4OEXdlz3nzByM+0dUnGrG5ms4m5rdSdHJnx/TU31k2DPBoV iqsjP6vGJMKtd4HF0QJFr3nCbOYv6pE+ODDGnOT8bFRvmM27We+UwQdxUFdNJ8xIyKA2 /ftQ== X-Gm-Message-State: AOAM531bNzMbCyRxBUXEmAzCcvuYUdfPrVFkfkFRae9x+PK3Qe9j2sYI iyq04uo+PFNLGBrh/T0I3+tKmSGSS/OOdQ== X-Google-Smtp-Source: ABdhPJzGU0VyF6yg/FmUH0Gs8sGXGBcPJXa9AhRWAuqgmCCf19/KyN6Eda2EVYUw3xWuqguFcwK+sg== X-Received: by 2002:a17:906:edc2:: with SMTP id sb2mr1004707ejb.159.1610403933803; Mon, 11 Jan 2021 14:25:33 -0800 (PST) Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com. [209.85.208.49]) by smtp.gmail.com with ESMTPSA id d4sm544553edq.36.2021.01.11.14.25.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 14:25:33 -0800 (PST) Received: by mail-ed1-f49.google.com with SMTP id i24so138263edj.8 for ; Mon, 11 Jan 2021 14:25:33 -0800 (PST) X-Received: by 2002:a2e:9ad7:: with SMTP id p23mr652511ljj.465.1610403510200; Mon, 11 Jan 2021 14:18:30 -0800 (PST) MIME-Version: 1.0 References: <20210110004435.26382-1-aarcange@redhat.com> <45806a5a-65c2-67ce-fc92-dc8c2144d766@nvidia.com> In-Reply-To: From: Linus Torvalds Date: Mon, 11 Jan 2021 14:18:13 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse To: John Hubbard Cc: 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 11:19 AM Linus Torvalds wrote: > > On Sun, Jan 10, 2021 at 11:27 PM John Hubbard wrote: > > IMHO, a lot of the bits in page _refcount are still being wasted (even > > after GUP_PIN_COUNTING_BIAS overloading), because it's unlikely that > > 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.. 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 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 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 (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. The whole "optimistic page references throigh page cache" etc are complete non-issues, because the whole point is that we already know it's not a page cache page. There is simply no other way to reach that page than through GUP. Ergo: any writable pte in a COW mapping that has a page with a page_count() > 1 is pinned by definition, and thus our page_maybe_dma_pinned(page) could remove that "maybe" part, and simply check for page_count(page) > 1 (although the rule would be that this is only valid for a cow_mapping pte, and only while holding the page table lock! So maybe it would be good to pass in the vma and have an assert for that lock too). And the thing is, none of the above rules are complicated. The only new one would be the requirement that you cannot add a page to the swap cache unless it is read-only in the page tables. That may be the biggest hurdle here. The way we handle swap cache is that we *first* add it to the swap cache, and then we do a "try_to_unmap()" on it. So we currently don't actually try to walk the page tables until we have already done that swap cache thing. But I do think that the only major problem spot is that shrink_page_list() -> add_to_swap() case, and I think we could make add_to_swap() just do the rmap walk and turn it read-only first. (And it's worth pointing out that I'm only talking about regular non-huge pages above, the rules for splitting hugepages may impact those cases differently, I didn't really even try to think about those cases). But thatadd_to_swap() case might make it too painful. It _would_ simplify our rules wrt anonymous mappings enormously, though. Linus