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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3D9A6C77B73 for ; Tue, 2 May 2023 19:00:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBD3A6B0081; Tue, 2 May 2023 15:00:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B46706B0082; Tue, 2 May 2023 15:00:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0D956B0083; Tue, 2 May 2023 15:00:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by kanga.kvack.org (Postfix) with ESMTP id 7AF0E6B0081 for ; Tue, 2 May 2023 15:00:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FvSMqnwpZ7YArJ7yAdLPKVO6ucbLedkU0RVbReJGMsg=; b=im1a3K9i2SW/qcYQ+dg7YIx54R rqscrI7KXcuedVTnRv1n+NvojKZ8Pv7yJ66Rw4J7w1GUOIvGxdWPY9o3J6bSmaNY7WypGTY5kFX6G 4fAfplgI0bffu7hYgq9CahhkRrCxbsclQIK0NDDndRSlyyUcZZxo9ce1rrzb39UXaHz7f6VHQkyd+ 2VKyz/QNJklZieaviHL5Uyk4p3FjzNvnl7ThlhtDQz+BPdeiJgIfAxCyJ8VO2dSMCh+JoOem2ypc/ hrxIhdofIBgvBLxhoYyV+nXLl3JnIPGV/t1H3b7ZLcslLCefANRiKQdnNwSgfeH9Q6kKGwHrq/haU 8dIy61iw==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1ptvDl-00GOxe-0W; Tue, 02 May 2023 18:59:29 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id D0D723033A5; Tue, 2 May 2023 20:59:26 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 89DBC241B3FAB; Tue, 2 May 2023 20:59:26 +0200 (CEST) Date: Tue, 2 May 2023 20:59:26 +0200 From: Peter Zijlstra To: David Hildenbrand Cc: Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jason Gunthorpe , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov , Jason Gunthorpe , John Hubbard , Jan Kara , "Kirill A . Shutemov" , Pavel Begunkov , Mika Penttila , Dave Chinner , Theodore Ts'o , Peter Xu , Matthew Rosato , "Paul E . McKenney" , Christian Borntraeger , Mike Rapoport Subject: Re: [PATCH v7 3/3] mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings Message-ID: <20230502185926.GE4253@hirez.programming.kicks-ass.net> References: <1691115d-dba4-636b-d736-6a20359a67c3@redhat.com> <20230502172231.GH1597538@hirez.programming.kicks-ass.net> <406fd43a-a051-5fbe-6f66-a43f5e7e7573@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406fd43a-a051-5fbe-6f66-a43f5e7e7573@redhat.com> 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 Tue, May 02, 2023 at 07:34:06PM +0200, David Hildenbrand wrote: > Now, if we read folio->mapping after checking if the page we pinned is still > mapped (PTE unchanged), at least the page we pinned cannot be reused in the > meantime. I suspect that we can still read "NULL" on the second read. But > whatever we dereference from the first read should still be valid, even if > the second read would have returned NULL ("rcu freeing"). Right, but given it's the compiler adding loads we're not sure what if anything it uses and it gets very hard to reason about the code. This is where READ_ONCE() helps, we instruct the compiler to only do a single load and we can still reason about the code.