From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 3F966359F9F; Wed, 21 Jan 2026 09:59:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768989556; cv=none; b=Ug8zAIMQJ7JJJNjHij5KXV3aq6nGcelQpOfHV6nfNkJwGP2tD+MXaZ+n69VkiobBjpR1O9qkHZRWkyIRp/38tEM8otb8LxKukSSaE/ByxRbxGqWlgBsh2EeSnwcxGWda4s8lQJEMZqKAeBc5lVuGIMibUpSJRmbRTojqVOSl358= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768989556; c=relaxed/simple; bh=T86hBBvfepicKUGBqX/8FhOUi0DjwHw8mEMM5b8bcH0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AAvdt8oGHid9y00YYkuJqMeE6UjhpAMYAPQACT2em9CkDEME5Pcd3t9ABjRcx7cpsrrUH9K208tPqdA3sVEgK8BzMOEnex+SotZoYOKyYgDojh8Phg34tnyyZIblykwva+JbyVq5mNiVz5hnbAuQtI7PfphyePXW4lgZAy6Rc6w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=GlzCRsx8; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="GlzCRsx8" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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=BIxfnTqIxfG/JDCpqz8ddR3KhEWm3MiBJqi238v5YU4=; b=GlzCRsx84vMm8sXEe178jEsMHi yEfsLuaiVDfKdvvIzvHHomVN4gwjGG/E7g6hvTZrX9Jl+jMggt9g7DJYZ9KBfIFzYhA3kss7211EY GEs0h/iYU1akVr821mpLBTcpxPKmjbRmaNEdphN9zpqkHbi/dWkZXm28+Sqj5tXo4XslET+sDAg7q 8tiAmX+5fSaGZCHmy/XD/afOXoGw6dcJ4dJHsPsM0/1AOYGnrcB/NtcMCkFeZvjwrcVtFQsDFGHap YeLREzyq2Ckz1YZlspGFTUyxh+vgvNaPEZGDQVL2D5WGr5K6wxV8nnmvIwla6TuNJ/6ZKDWgoUayq u8VgPgRQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1viUzJ-00000005EDM-2rax; Wed, 21 Jan 2026 09:58:57 +0000 Date: Wed, 21 Jan 2026 01:58:57 -0800 From: Christoph Hellwig To: Christian Brauner Cc: NeilBrown , Christoph Hellwig , Jeff Layton , Amir Goldstein , Alexander Viro , Chuck Lever , Olga Kornievskaia , Dai Ngo , Tom Talpey , Hugh Dickins , Baolin Wang , Andrew Morton , Theodore Ts'o , Andreas Dilger , Jan Kara , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , Carlos Maiolino , Ilya Dryomov , Alex Markuze , Viacheslav Dubeyko , Chris Mason , David Sterba , Luis de Bethencourt , Salah Triki , Phillip Lougher , Steve French , Paulo Alcantara , Ronnie Sahlberg , Shyam Prasad N , Bharath SM , Miklos Szeredi , Mike Marshall , Martin Brandenburg , Mark Fasheh , Joel Becker , Joseph Qi , Konstantin Komarov , Ryusuke Konishi , Trond Myklebust , Anna Schumaker , Dave Kleikamp , David Woodhouse , Richard Weinberger , Jan Kara , Andreas Gruenbacher , OGAWA Hirofumi , Jaegeuk Kim , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org, linux-xfs@vger.kernel.org, ceph-devel@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-unionfs@vger.kernel.org, devel@lists.orangefs.org, ocfs2-devel@lists.linux.dev, ntfs3@lists.linux.dev, linux-nilfs@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-mtd@lists.infradead.org, gfs2@lists.linux.dev, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support Message-ID: References: <9c99197dde2eafa55a1b55dce2f0d4d02c77340a.camel@kernel.org> <176877859306.16766.15009835437490907207@noble.neil.brown.name> <176880736225.16766.4203157325432990313@noble.neil.brown.name> <20260119-kanufahren-meerjungfrau-775048806544@brauner> <176885553525.16766.291581709413217562@noble.neil.brown.name> <20260120-entmilitarisieren-wanken-afd04b910897@brauner> <176890211061.16766.16354247063052030403@noble.neil.brown.name> <20260120-hacken-revision-88209121ac2c@brauner> Precedence: bulk X-Mailing-List: gfs2@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260120-hacken-revision-88209121ac2c@brauner> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Tue, Jan 20, 2026 at 11:31:54AM +0100, Christian Brauner wrote: > It is very much fine for a filesystems to support file handles without > wanting to support exporting via NFS. That is especially true for > in-kernel pseudo filesystems. I'm still amazed at this statement. "Wanting to export" is not something for the file system to decide on in any kind of sane layering. The file systems exports features, and layers higher in the stack make use of it. We just need to be precise in describing In-kernel code will then we so nice to respect it. But for userspace even then all bets are off.