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.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 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 4E8A8C433E0 for ; Fri, 15 Jan 2021 11:27:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B2D7A221F7 for ; Fri, 15 Jan 2021 11:27:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B2D7A221F7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DF3446B00B1; Fri, 15 Jan 2021 06:27:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DA2A28D015B; Fri, 15 Jan 2021 06:27:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDF948D0023; Fri, 15 Jan 2021 06:27:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0168.hostedemail.com [216.40.44.168]) by kanga.kvack.org (Postfix) with ESMTP id B8A966B00B1 for ; Fri, 15 Jan 2021 06:27:24 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7F0A5363F for ; Fri, 15 Jan 2021 11:27:24 +0000 (UTC) X-FDA: 77707783608.06.pot34_4f0c1f32752f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id 4AB931003E1D2 for ; Fri, 15 Jan 2021 11:27:24 +0000 (UTC) X-HE-Tag: pot34_4f0c1f32752f X-Filterd-Recvd-Size: 5667 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 Jan 2021 11:27:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4A57AACAC; Fri, 15 Jan 2021 11:27:22 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id AD77B1E0800; Fri, 15 Jan 2021 12:27:21 +0100 (CET) Date: Fri, 15 Jan 2021 12:27:21 +0100 From: Jan Kara To: John Hubbard Cc: Linus Torvalds , Andrea Arcangeli , 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 Subject: Re: [PATCH 2/2] mm: soft_dirty: userfaultfd: introduce wrprotect_tlb_flush_pending Message-ID: <20210115112721.GF27380@quack2.suse.cz> References: <20210107200402.31095-1-aarcange@redhat.com> <20210107200402.31095-3-aarcange@redhat.com> <4100a6f5-ab0b-f7e5-962f-ea1dbcb1e47e@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4100a6f5-ab0b-f7e5-962f-ea1dbcb1e47e@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 07-01-21 13:53:18, John Hubbard wrote: > On 1/7/21 1:29 PM, Linus Torvalds wrote: > > 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 > > What exactly did you have in mind, to make it stronger? I think the > answer is in this email but I don't quite see it yet... > > Also, now seems to be a good time to mention that I've been thinking about > a number of pup/gup pinning cases (Direct IO, GPU/NIC, NVMe/storage peer > to peer with GUP/NIC, and HMM support for atomic operations from a device). > And it seems like the following approach would help: > > * Use pin_user_pages/FOLL_PIN for long-term pins. Long-term here (thanks > to Jason for this point) means "user space owns the lifetime". We might > even end up deleting either FOLL_PIN or FOLL_LONGTERM, because this would > make them mean the same thing. The idea is that there are no "short term" > pins of this kind of memory. > > * Continue to use FOLL_GET (only) for Direct IO. That's a big change of plans, > because several of us had thought that Direct IO needs FOLL_PIN. However, this > recent conversation, plus my list of cases above, seems to indicate otherwise. > That's because we only have one refcount approach for marking pages in this way, > and we should spend it on the long-term pinned pages. Those are both hard to > identify otherwise, and actionable once we identify them. Somewhat late to the game but I disagree here. I think direct IO still needs FOLL_PIN so that page_may_be_dma_pinned() returns true for it. At least for shared pages. Because filesystems/mm in the writeback path need to detect whether the page is pinned and thus its contents can change anytime without noticing, the page can be dirtied at random times etc. In that case we need to bounce the page during writeback (to avoid checksum failures), keep page as dirty in internal filesystem bookkeeping (and in MM as well) etc... Honza -- Jan Kara SUSE Labs, CR