From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54DBD285CAD; Wed, 14 Jan 2026 15:26:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768404382; cv=none; b=ajxwF3B+1czPDqGKF+6LMqzGnYJD5m6osgvrsH77l1zydLegU9yrH8fpI9rhiwSvmt8/4lRuQ+5ieS2SWdDp0dpeokFvSh071QBj8y6CG8O3Hpx4tqIXf86f2pDoYUOFtogfMPFPQt0xHC4iRfK+VlI1MiN9tLJscxgZv03ZIhw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768404382; c=relaxed/simple; bh=TJ8HYpqwvKEu5WPBUCmrbZTfwhtmNo45dUDkhLnlTis=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eJmAjZhfumdJ8CDFQR6Sub3/ALcSaCIYpWzPqXwhH2J7/Zk5sq+GxlBURg3EB6B3+QgE4hf35ndcMWNlVJAvuZSFoQefVkrSrtdC0yBaZtc/y152GhUITxOCLE7ISCEFB87sri1ic+3SBdmmN4p8VOs02fUxIe2BXgeUCASnKX8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UuxL49Up; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UuxL49Up" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2C84C4CEF7; Wed, 14 Jan 2026 15:26:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768404382; bh=TJ8HYpqwvKEu5WPBUCmrbZTfwhtmNo45dUDkhLnlTis=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UuxL49UpINmE3bPn9I7g1qy3O1U7lEuEQBs6NY4FtevlZRrg+jir4TUf2JL5Et6S/ Wo3Rq7erhsD0wDrAjS0fAwtu2sdM1Ly6eiM6YJ56Efjw7Aqq9ho5u2uVmIb6CLm0qm DbkRjtkwVuzFS/3LLXXupO+XD87WN1YxMglF8PVz6z7zZF37PIEsEJLTAjeNY90c2+ Is57pvmqsqoUYUcAtHG3VWlWJm+iZsfwi7Dpki4E16iuG5isE531rPd5Kr9GSqblBC cmcig5bet6G0LrdDdcPVQ26rluu7tPoRJcI1jAeMRFhOX4YrFqzlg3FxIBJw/nlkLZ OyWqiHYjHhBJQ== Date: Wed, 14 Jan 2026 16:26:03 +0100 From: Christian Brauner To: Jeff Layton Cc: Christoph Hellwig , Amir Goldstein , Chuck Lever , Jan Kara , Luis de Bethencourt , Salah Triki , Nicolas Pitre , Anders Larsen , Alexander Viro , David Sterba , Chris Mason , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Jan Kara , Theodore Ts'o , Andreas Dilger , Jaegeuk Kim , OGAWA Hirofumi , David Woodhouse , Richard Weinberger , Dave Kleikamp , Ryusuke Konishi , Viacheslav Dubeyko , Konstantin Komarov , Mark Fasheh , Joel Becker , Joseph Qi , Mike Marshall , Martin Brandenburg , Miklos Szeredi , Phillip Lougher , Carlos Maiolino , Hugh Dickins , Baolin Wang , Andrew Morton , Namjae Jeon , Sungjong Seo , Yuezhang Mo , Alexander Aring , Andreas Gruenbacher , Jonathan Corbet , "Matthew Wilcox (Oracle)" , Eric Van Hensbergen , Latchesar Ionkov , Dominique Martinet , Christian Schoenebeck , Xiubo Li , Ilya Dryomov , Trond Myklebust , Anna Schumaker , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Tom Talpey , Bharath SM , Hans de Goede , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, linux-nilfs@vger.kernel.org, ntfs3@lists.linux.dev, ocfs2-devel@lists.linux.dev, devel@lists.orangefs.org, linux-unionfs@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, gfs2@lists.linux.dev, linux-doc@vger.kernel.org, v9fs@lists.linux.dev, ceph-devel@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org Subject: Re: [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support Message-ID: <20260114-blamabel-hanfernte-ea1345885b46@brauner> References: <20260113-mondlicht-raven-82fc4eb70e9d@brauner> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 14, 2026 at 08:41:16AM -0500, Jeff Layton wrote: > On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote: > > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig wrote: > > > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > > Fair point, but it's not that hard to conceive of a situation where > > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > > > Sure. But how is this worse than accidentally exporting private data > > > > or any other misconfiguration? > > > > > > > > > > My POV is that it is less about security (as your question implies), and > > > more about correctness. > > > > I was just replying to Jeff. > > > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > > open by file handle, IOW, the export_operations. > > > > > > I perceive this as a very strange and undesired situation when NFS > > > file handles do not behave as persistent file handles. > > > > That is not just very strange, but actually broken (discounting the > > obscure volatile file handles features not implemented in Linux NFS > > and NFSD). And the export ops always worked under the assumption > > that these file handles are indeed persistent. If they're not we > > do have a problem. > > > > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > > a known reason, which was NOT NFS export. > > > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > > wish to imply that those fs should be exported to NFS, why object? > > > > Because "want to export" is a stupid category. > > > > OTOH "NFS exporting doesn't actually properly work because someone > > overloaded export_ops with different semantics" is a valid category. > > > > cgroupfs definitely doesn't behave as expected when exported via NFS. > The files aren't readable, at least. I'd also be surprised if the > filehandles were stable across a reboot, which is sort of necessary for They aren't and it's not desirable.