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 A535BC7EE24 for ; Tue, 2 May 2023 13:47:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E7576B0072; Tue, 2 May 2023 09:47:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0706A900002; Tue, 2 May 2023 09:47:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E53336B0075; Tue, 2 May 2023 09:47:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by kanga.kvack.org (Postfix) with ESMTP id C3F0B6B0072 for ; Tue, 2 May 2023 09:47:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=gMkzwyLT/Xyxf8is/5S3+NSRKbTsmvleiqsCtxbzf8o=; b=lDgKY8pWgvaQIksEJVeLu2NKWR Jlz7kaZrEA+JA08BM+1VseVQkG441GBvgR24tACB+EBymntVCAzDbXHNJs1PdwckLuCJlKBb+QCyx nY3snqpW8fW+ykTn+5iqEC6yhVNvhO30scPF0Od5GxTNLIqtOuKQBQ3Y8tZ/aUANje1j7rD4QOWGm mK9OYMECjI/W9QFLwtxockb7D8sXqbrgXFHkY0udMrbB3iCKl2XYmFt4cVbywBY6fMcyDnepaIgTN /xT2sCi2HHWkHPLOoGNVEm439P3xjVSCTT4r9HimGel44cnWCXtAhsIEx24kI82KFIbVFnX4V6N7x aYOzgNfQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1ptlY8-00892R-Q5; Tue, 02 May 2023 08:39:52 +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) server-digest SHA256) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id C18EE3002BF; Tue, 2 May 2023 10:39:47 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3061A23C5C347; Tue, 2 May 2023 10:39:47 +0200 (CEST) Date: Tue, 2 May 2023 10:39:47 +0200 From: Peter Zijlstra To: Jan Kara Cc: "Kirill A . Shutemov" , David Hildenbrand , Peter Xu , Lorenzo Stoakes , Jason Gunthorpe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , 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 , John Hubbard , Pavel Begunkov , Mika Penttila , David Howells , Christoph Hellwig Subject: Re: [PATCH v5] mm/gup: disallow GUP writing to file-backed mappings by default Message-ID: <20230502083947.GE1597476@hirez.programming.kicks-ass.net> References: <6ddc7ac4-4091-632a-7b2c-df2005438ec4@redhat.com> <20230428160925.5medjfxkyvmzfyhq@box.shutemov.name> <39cc0f26-8fc2-79dd-2e84-62238d27fd98@redhat.com> <20230428162207.o3ejmcz7rzezpt6n@box.shutemov.name> <173337c0-14f4-3246-15ff-7fbf03861c94@redhat.com> <20230428165623.pqchgi5gtfhxd5b5@box.shutemov.name> <1039c830-acec-d99b-b315-c2a6e26c34ca@redhat.com> <20230428234332.2vhprztuotlqir4x@box.shutemov.name> <20230502080016.4tgmqb4sy2ztfgrd@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230502080016.4tgmqb4sy2ztfgrd@quack3> 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 10:00:16AM +0200, Jan Kara wrote: > On Sat 29-04-23 02:43:32, Kirill A . Shutemov wrote: > > I think I found relevant snippet of code that solves similar issue. > > get_futex_key() uses RCU to stabilize page->mapping after GUP_fast: > > > > > > /* > > * The associated futex object in this case is the inode and > > * the page->mapping must be traversed. Ordinarily this should > > * be stabilised under page lock but it's not strictly > > * necessary in this case as we just want to pin the inode, not > > * update the radix tree or anything like that. > > * > > * The RCU read lock is taken as the inode is finally freed > > * under RCU. If the mapping still matches expectations then the > > * mapping->host can be safely accessed as being a valid inode. > > */ > > rcu_read_lock(); > > > > if (READ_ONCE(page->mapping) != mapping) { > > rcu_read_unlock(); > > put_page(page); > > > > goto again; > > } > > > > inode = READ_ONCE(mapping->host); > > if (!inode) { > > rcu_read_unlock(); > > put_page(page); > > > > goto again; > > } > > > > I think something similar can be used inside GUP_fast too. > > Yeah, inodes (and thus struct address_space) is RCU protected these days so > grabbing RCU lock in gup_fast() will get you enough protection for checking > aops if you are careful (like the futex code is). GUP_fast has IRQs disabled per definition, there is no need to then also use rcu_read_lock().