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 A7826C433E0 for ; Mon, 11 Jan 2021 01:18:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2BF3E2229C for ; Mon, 11 Jan 2021 01:18:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BF3E2229C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CE4CC6B00F1; Sun, 10 Jan 2021 20:18:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C70916B00F2; Sun, 10 Jan 2021 20:18:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B0F756B0108; Sun, 10 Jan 2021 20:18:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0040.hostedemail.com [216.40.44.40]) by kanga.kvack.org (Postfix) with ESMTP id 965C66B00F1 for ; Sun, 10 Jan 2021 20:18:40 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 590F8180AD806 for ; Mon, 11 Jan 2021 01:18:40 +0000 (UTC) X-FDA: 77691734400.17.verse52_3e1690427508 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 31608180D0186 for ; Mon, 11 Jan 2021 01:18:40 +0000 (UTC) X-HE-Tag: verse52_3e1690427508 X-Filterd-Recvd-Size: 6058 Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 11 Jan 2021 01:18:39 +0000 (UTC) Received: by mail-io1-f42.google.com with SMTP id q1so1783333ion.8 for ; Sun, 10 Jan 2021 17:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+NrnyZaq7NMDmL0oQZNOQS7o3D1qvxpQlNe+NJXrQZA=; b=pEOVX2qcwhXtTq/f3IeKVXWqsuiDDa/iLlSDYm5CzthH6/M6LsrHdCA/eTub0UcETe oCapk6sAy1cVrx6knya2bMx5iH7mjwwJn3a0ojAbe8qW3fpo3yFm3KttYuecuADNKjAP +/lME2OLTUixfGgwPzYpoJ3Im0OPDsK/mQeda/Uikh7Q8dAMOnfVndhkpiwbteeqHyiB QQKEGaL/i3npr9YDd12WrB9Kat5cJjkiW0uG5CmZj+Q3MkGqDG7dQd06LFbwwijrslGn 2D4x+f+6bqYRFOzqdlZhhMMRcbM2exRm4NxW42hU4sCSbLTRHAILPJYhiIKoYRlfYXK6 rwFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=+NrnyZaq7NMDmL0oQZNOQS7o3D1qvxpQlNe+NJXrQZA=; b=fF20XfcqTH78smqAqoJv8uq0i4hh4RjrVbpAwJ7xxTsJjDUEqyA/lHwxyla+5ZJLtb AOahgRINQETCtrKBpY6cwVlh3uiBgaVX+4+BLcfD4iq7ZB+8mbaiMuT4UL2X2b4AZlkU S3KDHrUAawsxnwrW10kwQD/q5LmrQjE1rWvxKBcgrf2VsRdCqiE0s0n2tUjLFoO1z/rG D4skbIf46Pt55Fin2StkieDGlisHiMX9Fz6Ae3wvVJ4bnTvfvTqrCrGnxg4dj1JSxH0u avT6gI7Xhx4QpcDFlj1QpUDMkm+Kk04Z+aGDg8N8dRMqKV1Fvcn/vZHITU+GgZ19fJbD Z2nQ== X-Gm-Message-State: AOAM533OtdlhKPZcQ6L0A3MqYLzjlVqSA1Zb7B47bSOWfnjFyT1YSJjA bYlvv/Wyj/tw9NmZoNbzx4Pa9A== X-Google-Smtp-Source: ABdhPJwfjHPhqnVLvq1fzQka3jPqKfPQRjWODvzOBEtzJhyuog8aE+wcZVY71r9NiIP4PoCZ29/xnA== X-Received: by 2002:a6b:6106:: with SMTP id v6mr13275198iob.39.1610327919037; Sun, 10 Jan 2021 17:18:39 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id h70sm10410939iof.31.2021.01.10.17.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Jan 2021 17:18:38 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kylqv-005JaH-78; Sun, 10 Jan 2021 21:18:37 -0400 Date: Sun, 10 Jan 2021 21:18:37 -0400 From: Jason Gunthorpe To: Linus Torvalds 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 , John Hubbard , Leon Romanovsky , Jan Kara , Kirill Tkhai , Nadav Amit , Jens Axboe Subject: Re: [PATCH 0/1] mm: restore full accuracy in COW page reuse Message-ID: <20210111011837.GH504133@ziepe.ca> References: <20210110004435.26382-1-aarcange@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Sun, Jan 10, 2021 at 11:30:57AM -0800, Linus Torvalds wrote: > Notice how this is all both conceptually fairly simple (ie I can > explain the rules in plain English without really making any complex > argument) and it is arguably internally fairly self-consistent (ie the > whole notion of "oh, there's another thing that has write access that > page but doesn't go through the page table, so trying to make it > read-only in the page tables is a nonsensical operation"). Yes exactly! > Are the end results wrt something like soft-dirty a bit odd? Not > really. If you do soft-dirty, such a GUP-shared page would simply > always show up as dirty. That's still consistent with the rules. If > somebody else may be writing to it because of GUP, that page really > *isn't* clean, and us marking it read-only would be just lying about > things. > > I'm admittedly not very happy about mprotect() itself, though. It's > actually ok to do the mprotect(PROT_READ) and turn the page read-only: > that will also disable COW itself (because a page fault will now be a > SIGSEGV, not a COW). I would say even mprotect should not set write protect on page under DMA, it seems like the sort of thing that will trip up other parts of the mm that might sensibly assume read-only actually means read only, not 'probably read-only but there might be DMA writes anyhow' So copy the page before write protecting it? Then the explicit mprotect is one of the system calls that can cause de-coherence of the DMA - like munmap. If we had reliable pinned detection I'd say to fail the mprotect.. And I think you are right about clear refs too. Clear refs must be aware of FOLL_LONGTERM and handle it properly - which includes not write protecting such a page. Jason