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 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