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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 72438CAC5A5 for ; Sat, 20 Sep 2025 18:09:35 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4cTcpP52LJz2yN1; Sun, 21 Sep 2025 04:09:33 +1000 (AEST) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip="2a03:a000:7:0:5054:ff:fe1c:15ff" ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1758391773; cv=none; b=mQEdm2vnywek8ts43kek3DtluVTgVRA4tWHjnvYmpNu6wq7BWGUgAgA5z95uJDdj6OOU9XeZnwAu7+1DNtyOlbuqqrFjSNitoe/vU0Yd/vwmZCx89xK435h/WJbNL7ng6HKcmB+7tvA2hkzyWqP9acJ0/WzgChCPwvGurXT1IWrBJ5hQTYVsyQIUW6s7zOGWLRM0Z8MwG6TMnA+fieTJTZF4hENKuJOrDNtwSIsTfjgQd6HhHz1N21RR4BZrIKAGur7F0zU0YDHt9klcWLK1GNj/8KbUKeXnQQQUfUexTE+bCBKFJCkDVrleyNISF7Up8LURkpUdsLkVKMO91ykAzw== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1758391773; c=relaxed/relaxed; bh=6NL30/0+UZmJ+Ndqi2NTqpdBOV8RvNTpTtq6rtRPK9E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=adSzwx63Stve4QgUixlcDs5ALXZO+i9LbYAANNKOTNlKfXbQCFeuguksA0ARvtwtgjKPpR0Cb6ge1PCJEYM7v4x3LFm5XLQ6+KEX2NEOG7eYIaVDOvW4oOTEVwPnaY+0jM8W9QbgBVk2WxzZNA5g+v+2uik/hZ7VqMJY5o4p39vHK92n3tt95eVoHdG0EBGXcSiwHp/zSujaUNNcEPhECd9TxU+iCe/Yq+Qp08L2cIKwDD4q1DIQ0Fgaa1dQDWAtoRYK6WMcX0sEaeWo4vmuSAXDjPUbUXB/63MBpWHbdDB2tBGVaUkrxTkabGk9rdVeYWJZZlk1N9wrPg5ujdwm0A== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; dkim=pass (2048-bit key; unprotected) header.d=linux.org.uk header.i=@linux.org.uk header.a=rsa-sha256 header.s=zeniv-20220401 header.b=NM79fJk4; dkim-atps=neutral; spf=none (client-ip=2a03:a000:7:0:5054:ff:fe1c:15ff; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=lists.ozlabs.org) smtp.mailfrom=ftp.linux.org.uk Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=linux.org.uk header.i=@linux.org.uk header.a=rsa-sha256 header.s=zeniv-20220401 header.b=NM79fJk4; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=ftp.linux.org.uk (client-ip=2a03:a000:7:0:5054:ff:fe1c:15ff; helo=zeniv.linux.org.uk; envelope-from=viro@ftp.linux.org.uk; receiver=lists.ozlabs.org) Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4cTcpN59t9z2xpn for ; Sun, 21 Sep 2025 04:09:31 +1000 (AEST) 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=6NL30/0+UZmJ+Ndqi2NTqpdBOV8RvNTpTtq6rtRPK9E=; b=NM79fJk4vVddI7amyfuuFalCjV KCwjdAr3TBi8ShghGh7DNgYuVH9L+WE3QjtxSRg3IZBe1atmcEKyONCQj9I3wo/0CEGQOZou4azRK 2+7qBlOTxdA1xp127r7u5bM6TjwF9mONn+nwL5XucvYd3CZuGSX3BA5ysms187Yyj/wF6/86/CmTL WC2z/0mRVx9nm5VEhTaqI7AesxCZh6k1F+Lpz9Pus6qr4SxsrrMPq2R9tjnbIPN4krYN0ZoLm1Cek ZI6tJ4FtKRcLJdSKn5AdIr/wOwwbdc4jFYT2UcYCQC/FIOU5oSOQeuYce7ptP2b4JNzeCtNGNm6Zd bQgwQelw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1v021O-000000039W5-3GQv; Sat, 20 Sep 2025 18:09:18 +0000 Date: Sat, 20 Sep 2025 19:09:18 +0100 From: Al Viro To: Linus Torvalds Cc: linux-fsdevel@vger.kernel.org, Christian Brauner , Jan Kara , Ian Kent , Miklos Szeredi , Andreas Hindborg , linux-mm@kvack.org, linux-efi@vger.kernel.org, ocfs2-devel@lists.linux.dev, Kees Cook , Steven Rostedt , Greg Kroah-Hartman , linux-usb@vger.kernel.org, Paul Moore , Casey Schaufler , linuxppc-dev@lists.ozlabs.org, Christian Borntraeger Subject: Re: [PATCHES][RFC] the meat of tree-in-dcache series Message-ID: <20250920180918.GL39973@ZenIV> References: <20250920074156.GK39973@ZenIV> X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro On Sat, Sep 20, 2025 at 09:26:27AM -0700, Linus Torvalds wrote: > Anyway, apart from that I only had one reaction: I think > d_make_discardable() should have a > > WARN_ON(!(dentry->d_flags & DCACHE_PERSISTENT)) > > because without that I think it can mistakenly be used as some kind of > "dput that always takes the dentry lock", which seems bad. > > Or was that intentional for some reason? In the end - sure, we want that. But in the meanwhile that would require separate variants of simple_unlink()/simple_recursive_removal()/etc. for those filesystems that are already marking persistent ones, with the only difference being that warning. A lot more noise that way. So I'd prefer to put a warning in the source for the time being. In principle, by the end of series as posted we are down to very few filesystems that use simple_unlink() and friends without having marked them persistent in the first place, so it would be possible to put a "make d_make_discardable() warn if it's not marked persistent, add variants of simple_unlink()/simple_rmdir()/ simple_recursive_removal()/locked_recursive_removal() that would *NOT* warn and switch the handful of unconverted users to calling those", but... By the end of series as posted that's down to nfsctl, rpc_pipe, securityfs, configfs and apparmorfs. The first 3 - because they used to have subseries of their own in separate branches, with corresponding conversion commits sitting on top of merges (#work.nfsctl is the last of those branches). No real obstacle to moving them into the queue, I just wanted to post it for review before we get to -rc7. The remaining two (configfs and apparmor) are special enough to warrant private copies of simple_{unlink,rmdir}(). So I'd rather have that in patch adding the warning - simple_recursive_remove() wouldn't need a separate copy that way at all. configfs has a separate series untangling it, but that's a separate story - that work goes back to 2018; I want to resurrect it, but I'm not mixing it into this pile. appramor is... special. They've got locking of their own, completely broken and interspersed with regular directory locks. John Johansen, if I understood him correctly, has some plans re fixing that, and I'm happy not to have analysis of their locking on my plate. _Maybe_ it will end up close enough to the usual tree-in-dcache to switch to that stuff, but at the moment I'd rather open-code simple_{unlink,rmdir} in aafs_remove() and leave it at that.