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 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.lore.kernel.org (Postfix) with ESMTPS id D98B1D46940 for ; Wed, 21 Jan 2026 14:47:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VyhpmbBjgAargqsdGrSuxKLdLzh/b4keMrhSPE+dV7U=; b=ByWKvvAo7Nws66 epwN4ZirX1gt0JL6j5UWJSviqUwv1krBmx6HfmYujpeqX9YNSQZ1Nt8UA63qc3C0iAp5v2Goz31DI UJDZYS8XQyggrJe20SKfmdt7gJsK1NNMwXw/8+axH309xZtI/4Y5MenFUqQX8HQXP0PIpSpuHPgX4 igJnzeAdPy8cYJk/JZvKtwmoCFOmioHsKFGT7Lxkx7pS0EXJfPaJDBuJ0YXpc+5grxPLMbYqgyhuJ 7aC0kFDLDuWce3nDitaogUNCxo5bBsqmorN6WMD1sZ3u98NdwBq1UOzGqTnDYaVy/3ei4SOdXmNDD EHBqFRELHiO/Nu8yvaUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1viZUR-00000005dYq-0VRp; Wed, 21 Jan 2026 14:47:23 +0000 Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1viZUG-00000005dMj-1Wd9; Wed, 21 Jan 2026 14:47:12 +0000 Date: Wed, 21 Jan 2026 06:47:12 -0800 From: Christoph Hellwig To: Jeff Layton Cc: NeilBrown , Christoph Hellwig , Christian Brauner , 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: <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> <176890126683.16766.5241619788613840985@noble.neil.brown.name> <176899164457.16766.16099772451425825775@noble.neil.brown.name> <364d2fd98af52a2e2c32ca286decbdc1fe1c80d3.camel@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <364d2fd98af52a2e2c32ca286decbdc1fe1c80d3.camel@kernel.org> X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Wed, Jan 21, 2026 at 09:27:38AM -0500, Jeff Layton wrote: > Using your definitions, stability is not a problem for Linux > filesystems. The filehandles generally don't change after they have > been established. fat seems to be an exception as far as the 'real' file systems go. And it did sound to me like some of the synthetic ones had similar issues. > > We'll still need a stable handles flag, and expose it to userspace > > to avoid applications being tricked into using broken non-stable > > file handles. We should have caught that when they were added, but > > didn't unfortunately. > > > > If we assume he meant "unique handles" flag, then I think we're all > mostly in agreement here. As far as this patchset goes: what if we > were to just rename EXPORT_OP_STABLE_HANDLES to > EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's > the main issue for existing filesystems. It would be fairly simple to > advertise handle uniqueness using statx or something. Unique seems to also only capture part of it, but I could absolutely live with it, if the documentation includes all aspecs. But maybe use persistent as in the nfs spec? > > Alternately, instead of denying access to these filesystems, we could > just fix these filesystems to create unique handles (a'la random > i_generation value or something similar). That should mostly prevent > filehandles from being reusable across a reboot on these filesystems. Do we even want to provide access to them? > That would leave cgroupfs and the like exportable via nfsd, but as you > point out, we can't deny export by userland servers. If people want to > do this kind of crazy stuff, maybe we shouldn't deny them after all. I think Amirs patch would take care of that. Although userland nfs servers or other storage applications using the handle syscalls would still see them. Then again fixing the problem that some handles did not fulfill the long standing (but not documented well enough) semantics probably is a good fix on it's own. ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/