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 C7446C433DB for ; Thu, 7 Jan 2021 21:36:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A159235FC for ; Thu, 7 Jan 2021 21:36:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A159235FC 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 6280D6B0155; Thu, 7 Jan 2021 16:36:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B2186B0156; Thu, 7 Jan 2021 16:36:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47C046B0157; Thu, 7 Jan 2021 16:36:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id 2A2316B0155 for ; Thu, 7 Jan 2021 16:36:23 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E2744181AEF31 for ; Thu, 7 Jan 2021 21:36:22 +0000 (UTC) X-FDA: 77680287804.11.snake64_5412725274ed Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id C04E8180F8B80 for ; Thu, 7 Jan 2021 21:36:22 +0000 (UTC) X-HE-Tag: snake64_5412725274ed X-Filterd-Recvd-Size: 5934 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf49.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Jan 2021 21:36:22 +0000 (UTC) Received: by mail-lf1-f48.google.com with SMTP id x20so17989086lfe.12 for ; Thu, 07 Jan 2021 13:36:22 -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=ro2IhvHCEBNP9++3a82oNOJWhTjhblGinExSmTI8Qj+X2GrODR6C//CPf/1tKE0Wda g2BTjjP6mABMGS8VeL4rq6JXdk0TlnGkBdvdGkg+MUX4Vy1KbOf3b6wIXuSGQnM4lH88 8zSc7ZPH34v2IZNnc5rBVQDGbAOG/uB+3N8ZnzKD55Qh0oo7an388WUJyPa4rn238t8K qehqKq6JYIWyMb97pY+EiQCRsqXJqfcWu2lEFZ7JkjDVAFQbT5Hz0EHea3LHrPAaMfir GTnlr9TBXID3M6VXv1QS+fWMuq6ownt1LGlR3K97WG5vY4dIw5LktKWgkQpVJ5f73xRr FqnA== X-Gm-Message-State: AOAM531TrMzi1JIDI3MGg8Ce1ZUEjKcVKrbaI53NuHTGr1WIfRcMJR+8 lp70zQJ8zaMvrlqYpmRtv+zpwZ1ZDz6Tgw== X-Google-Smtp-Source: ABdhPJxknsuolgwwxJMV/q7Kw8jRRpt+z/TGL4A6zmiWUbCP6Si+VpTZs8fUSko2vKDnxdeUzZ42bA== X-Received: by 2002:a19:3c5:: with SMTP id 188mr282394lfd.202.1610055380525; Thu, 07 Jan 2021 13:36:20 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com. [209.85.167.50]) by smtp.gmail.com with ESMTPSA id z9sm1424486lfb.287.2021.01.07.13.36.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jan 2021 13:36:20 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id o10so7172022lfl.13 for ; Thu, 07 Jan 2021 13:36:20 -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" 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 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