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 B0959C77B73 for ; Tue, 2 May 2023 16:16:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 431C1900003; Tue, 2 May 2023 12:16:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E1A8900002; Tue, 2 May 2023 12:16:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D0C7900003; Tue, 2 May 2023 12:16:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by kanga.kvack.org (Postfix) with ESMTP id E6EA0900002 for ; Tue, 2 May 2023 12:16:10 -0400 (EDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 9E54422316; Tue, 2 May 2023 08:00:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1683014417; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NP9x04IpamZ+4J4+YQ6L241Lqle1HdNEDLK94FhKL1s=; b=i0Ht6owzagxVsusrh+k5TXS/6F2cGI8FuxyGJtxaFJRM4m4Tbvw8zxYpoPAbak19HBxF5W cxJXamUCHUZLnK6iJcMa2ugn7dBT0o4+Usv0KcVpqAJ9chkraDeslIW2T4hEJ5YlEX4YME 8K8Dtc7Sx2s/ac0VicMWDMCjyyb5saQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1683014417; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NP9x04IpamZ+4J4+YQ6L241Lqle1HdNEDLK94FhKL1s=; b=F85KhN7n9ZQMG5OTs4r7YsDZdS0LgI/nHqlYSWjEfVtH7P6F5XG6gXBa2RHb8jxNFawQrD W5FFX4gWEOqqNXDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6DE96134FB; Tue, 2 May 2023 08:00:17 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id HTxOGxHDUGTwIwAAMHmgww (envelope-from ); Tue, 02 May 2023 08:00:17 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id A2D8AA0735; Tue, 2 May 2023 10:00:16 +0200 (CEST) Date: Tue, 2 May 2023 10:00:16 +0200 From: Jan Kara To: "Kirill A . Shutemov" Cc: 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 , Peter Zijlstra , 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 , Jan Kara , 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: <20230502080016.4tgmqb4sy2ztfgrd@quack3> References: <62ec50da-5f73-559c-c4b3-bde4eb215e08@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230428234332.2vhprztuotlqir4x@box.shutemov.name> 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 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). Honza -- Jan Kara SUSE Labs, CR