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 0BF5DCCA47C for ; Tue, 5 Jul 2022 03:49:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 651BF6B0073; Mon, 4 Jul 2022 23:49:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 602C36B0074; Mon, 4 Jul 2022 23:49:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4CBCA6B0075; Mon, 4 Jul 2022 23:49:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3D74A6B0073 for ; Mon, 4 Jul 2022 23:49:57 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 16DF36DF for ; Tue, 5 Jul 2022 03:49:57 +0000 (UTC) X-FDA: 79651667634.08.A013B61 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) by imf05.hostedemail.com (Postfix) with ESMTP id 9F89410000A for ; Tue, 5 Jul 2022 03:49:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WiklvS9k0el8XhEQTp2AsFsJfZTmp2j5g87JdjG5LuY=; b=A6t/lG34n3OcVFs5zHW4rDAgZU dB25v6MxiCdWY7bmdH/wWMwaUIjPEoO1NWhXrC7y6CSmgLDL6bimS/XngJ2GfM7RDrgo98UN/Hj5w phxCr6dVDxHMO5OyImVJNe+pBY/kpdH+uHILtmM5FEJN5dminDlfCj7TB7tUgjynMeYgPLR9ZJLg6 5iq4kIYJ9iFtlCfW/XX9hM6JjSG8RfvMehgbWUy1/mO7jhrbxMHwv6wuVdX66t8kIJebaxLKtFSpY JUWGP8LidNDDQzx7AI81vdD7vBuNViIZtGOuVxRemJ+Jh/b9pHi+7NtjZp1cROsoB+T5lnwoKjDFA yiZQuu/A==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1o8ZYY-008EUH-Gz; Tue, 05 Jul 2022 03:48:58 +0000 Date: Tue, 5 Jul 2022 04:48:58 +0100 From: Al Viro To: Linus Torvalds Cc: Alexander Potapenko , Alexei Starovoitov , Andrew Morton , Andrey Konovalov , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Christoph Hellwig , Christoph Lameter , David Rientjes , Dmitry Vyukov , Eric Dumazet , Greg Kroah-Hartman , Herbert Xu , Ilya Leoshkevich , Ingo Molnar , Jens Axboe , Joonsoo Kim , Kees Cook , Marco Elver , Mark Rutland , Matthew Wilcox , "Michael S. Tsirkin" , Pekka Enberg , Peter Zijlstra , Petr Mladek , Steven Rostedt , Thomas Gleixner , Vasily Gorbik , Vegard Nossum , Vlastimil Babka , kasan-dev , Linux-MM , linux-arch , Linux Kernel Mailing List , Evgenii Stepanov , Nathan Chancellor , Nick Desaulniers , Segher Boessenkool , Vitaly Buka , linux-toolchains Subject: Re: [PATCH 1/7] __follow_mount_rcu(): verify that mount_lock remains unchanged Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="A6t/lG34"; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf05.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656992996; a=rsa-sha256; cv=none; b=qmMPnlEnX+9Yv3SOghXOIqPglh8Ww/gep9G5fvzY4Vm35ivqTv9D10alGG6lEBQLV+DVX7 +tdNGXGRg7X6+6m6SwvedbJyCbcnPj2v1mYRsSs4KW/n8CZvYSfMyUEp54OlCKfBUXc5fs MycMOP47d6iMH8+JErea7vMykIAJteA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656992996; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WiklvS9k0el8XhEQTp2AsFsJfZTmp2j5g87JdjG5LuY=; b=vAiJ95Q4S3A4Rk3qTPa6cFP7ZyTxLHbGhGPGtln1jEvPSu15+fm72Z2VVaCH00r0ThqizN KAkTZJ0Jw13s9iwdGYedk6yioXSjp41ovR6N8Eq8khmx9/hKZYWm7bNupMOGvJCoUjO40g c4gZcpJf73RFLlZMCa4O+KLUMRRq7m8= Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux.org.uk header.s=zeniv-20220401 header.b="A6t/lG34"; dmarc=pass (policy=none) header.from=zeniv.linux.org.uk; spf=none (imf05.hostedemail.com: domain of viro@ftp.linux.org.uk has no SPF policy when checking 62.89.141.173) smtp.mailfrom=viro@ftp.linux.org.uk X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: dqufm7oht4ux771pr3bmgytgrkpcgrwf X-Rspamd-Queue-Id: 9F89410000A X-HE-Tag: 1656992993-707652 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 Mon, Jul 04, 2022 at 05:06:17PM -0700, Linus Torvalds wrote: > I wonder if the solution might not be to create a new structure like > > struct rcu_dentry { > struct dentry *dentry; > unsigned seq; > }; > > and in fact then we could make __d_lookup_rcu() return one of these > things (we already rely on that "returning a two-word structure is > efficient" elsewhere). > > That would then make that "this dentry goes with this sequence number" > be a very clear thing, and I actually thjink that it would make > __d_lookup_rcu() have a cleaner calling convention too, ie we'd go > from > > dentry = __d_lookup_rcu(parent, &nd->last, &nd->next_seq); > > rto > > dseq = __d_lookup_rcu(parent, &nd->last); > > and it would even improve code generation because it now returns the > dentry and the sequence number in registers, instead of returning one > in a register and one in memory. > > I did *not* look at how it would change some of the other places, but > I do like the notion of "keep the dentry and the sequence number that > goes with it together". > > That "keep dentry as a local, keep the sequence number that goes with > it as a field in the 'nd'" really does seem an odd thing. So I'm > throwing the above out as a "maybe we could do this instead..". I looked into that; turns out to be quite messy, unfortunately. For one thing, the distance between the places where we get the seq count and the place where we consume it is large; worse, there's a bunch of paths where we are in non-RCU mode converging to the same consumer and those need a 0/1/-1/whatever paired with dentry. Gets very clumsy... There might be a clever way to deal with pairs cleanly, but I don't see it at the moment. I'll look into that some more, but... BTW, how good gcc and clang are at figuring out that e.g. static int foo(int n) { if (likely(n >= 0)) return 0; .... } .... if (foo(n)) whatever(); should be treated as if (unlikely(foo(n))) whatever(); They certainly do it just fine if the damn thing is inlined (e.g. all those unlikely(read_seqcount_retry(....)) can and should lose unlikely), but do they manage that for non-inlined functions in the same compilation unit? Relatively recent gcc seems to...