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 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 23423C433E0 for ; Thu, 7 Jan 2021 21:31:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DC65A235DD for ; Thu, 7 Jan 2021 21:31:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727519AbhAGVap (ORCPT ); Thu, 7 Jan 2021 16:30:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726052AbhAGVao (ORCPT ); Thu, 7 Jan 2021 16:30:44 -0500 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD5B0C0612F4 for ; Thu, 7 Jan 2021 13:30:03 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id s26so18000943lfc.8 for ; Thu, 07 Jan 2021 13:30:03 -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=qFwN+Sq2XfTerk/A+8SrWgplwXo55fv0jGeOVi5rS8A=; b=e4znJYsrF7HpZFiMj84eCu2UTWCl7asCEAgLSU2rZ8eobsfy6Befvf0MgrlbHOyogY NwGn2SYwqlGxT+EcquTQf/V5fTvmSJ9thicygv4XU5R5QV0Q6cXVQwi+FiemijIkh+67 iUrnU8a/sj1R9Mo025blPYO4/4H25kw7YBT0U= 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=qFwN+Sq2XfTerk/A+8SrWgplwXo55fv0jGeOVi5rS8A=; b=kkmTBiS/rTpaU+ZtyGEs0RiJMT2Du1A2nEvBIhahK7xi/vqLGSZ/sV3oyrLBFtUSBd F6qOCiIarUHmXJQxgR2mZGEowT6DFR1OZmKhYkK+QK0dujDYkS/KiKFwHuCE95fHsAz7 WkSpmKmYlfDjLgsus1ibtOCoTuWpB/zA3praFfichG6dvy1rDFX94yRXtLLwWTELVkh8 khxeZ+sDKx1idG0loX7v76HJ4pPoFAiTQQ0Hm/tCXR8X0sTHyN3jFWvm7qPM9E8WXj8k k51+kQd8sRRnNdByWBt7Hd820gPKmB3LU0Rin8K6WZ1hgwDzgO9jT2Q4dsjR5qeZThGh /LHQ== X-Gm-Message-State: AOAM531KUqj1tevMtlhfcK3i14M45O7Q46a+W+EeEtrT62+0FttMq2qS NqH1G0q0m3akXFqxgJdNq1LGJmnGVJpXKA== X-Google-Smtp-Source: ABdhPJw3vdGsQBsDEKBGadqLWMYMItXU8CJk4KiRxDtFWUiPKQe/9BQhcjoFYhW8N6NHRUPDVhYNLg== X-Received: by 2002:a19:cbd4:: with SMTP id b203mr307233lfg.506.1610055001740; Thu, 07 Jan 2021 13:30:01 -0800 (PST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id x17sm1436396lfg.0.2021.01.07.13.30.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 13:30:00 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id l11so18143271lfg.0 for ; Thu, 07 Jan 2021 13:30:00 -0800 (PST) X-Received: by 2002:ac2:4987:: with SMTP id f7mr266319lfl.41.1610054999854; Thu, 07 Jan 2021 13:29:59 -0800 (PST) MIME-Version: 1.0 References: <20210107200402.31095-1-aarcange@redhat.com> <20210107200402.31095-3-aarcange@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 7 Jan 2021 13:29:43 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 2/2] mm: soft_dirty: userfaultfd: introduce wrprotect_tlb_flush_pending To: Andrea Arcangeli Cc: 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 , John Hubbard , Leon Romanovsky , Jason Gunthorpe , Jan Kara , Kirill Tkhai Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 7, 2021 at 12:59 PM Andrea Arcangeli wrote: > > The problem is it's not even possible to detect reliably if there's > really a long term GUP pin because of speculative pagecache lookups. So none of the normal code _needs_ that any more these days, which is what I think is so nice. Any pinning will do the COW, and then we have the logic to make sure it stays writable, and that keeps everything nicely coherent and is all fairly simple. And yes, it does mean that if somebody then explicitly write-protects a page, it may end up being COW'ed after all, but if you first pinned it, and then started playing with the protections of that page, why should you be surprised? So to me, this sounds like a "don't do that then" situation. Anybody who does page pinning and wants coherency should NOT TOUCH THE MAPPING IT PINNED. (And if you do touch it, it's your own fault, and you get to keep both of the broken pieces) Now, I do agree that from a QoI standpoint, it would be really lovely if we actually enforced it. I'm not entirely sure we can, but maybe it would be reasonable to use that mm->has_pinned && page_maybe_dma_pinned(page) at least as the beginning of a heuristic. In fact, I do think that "page_maybe_dma_pinned()" could possibly be made stronger than it is. Because at *THAT* point, we might say "we know a pinned page always must have a page_mapcount() of 1" - since as part of pinning it and doing the GUP_PIN, we forced the COW, and then subsequent fork() operations enforce it too. So I do think that it might be possible to make that clear_refs code notice "this page is pinned, I can't mark it WP without the pinning coherency breaking". It might not even be hard. But admittedly I'm somewhat handwaving here, and I might not have thought of some situation. Linus