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.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (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 34F7BC44536 for ; Wed, 21 Jan 2026 14:48:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.sourceforge.net; s=beta; h=Content-Transfer-Encoding:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: Subject:In-Reply-To:MIME-Version:References:Message-ID:To:From:Date:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=szsfdexsbm8glzSiaYAs57TMGgc/3AAGVh0rOY6A5Cs=; b=DUMiw4T9T1AkvHofeJs3NbjLWu MZycKc702O6Y1mEqDfBxTty9WOPtclNdzMzwLhDh2Vr3IExqKXCBtsHGmTWN35ZJ70jmN/HJuSHJJ 5pVtOJFiXJPbPb5Gl5604Ouqz4J9SAnzon68OdBNj0CdCX1mN55bxgL8Q2j4EjAEKsps=; Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1viZV0-0004rg-IE; Wed, 21 Jan 2026 14:47:58 +0000 Received: from [172.30.29.66] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1viZUw-0004rM-89; Wed, 21 Jan 2026 14:47:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; 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:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=edtMn02AVod+IBbJIVsMu3fhJTzD4OTVoerhqOtkeWk=; b=G2KTxqHYCohsIWG2KboWMwJMZD 6Yw5GGAnxpzQKRwSME6LeRSj+154gexFe1h5VjOFO9rr0q4/2CJ6o7nJOlAiCPQchlrfaDeZE+mys Ac1NtEHOUYLJqfEXu2ogH342efv+IaYS3YTEOOJ2N6nQPUjYYlxXD6Jrfre26XCUS8P4=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; 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:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=edtMn02AVod+IBbJIVsMu3fhJTzD4OTVoerhqOtkeWk=; b=Lv9fe63oGJ9FIeueCdBzXDqCR7 4vYy4xWzzsOurBTehksSG88jK1pCE9VCIa88s3lnaheWJ2Hfy3cEBhqAB5sXk837+QY1zixBuqKiS U5ZO9aLi9AjKlxvRARIarVsOSLi/xG3sdKpAjzY6OO55xDqPfqMjz2XfSfoMmUJsN2h4=; Received: from bombadil.infradead.org ([198.137.202.133]) by sfi-mx-2.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1viZUu-0002nT-Ln; Wed, 21 Jan 2026 14:47:54 +0000 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=edtMn02AVod+IBbJIVsMu3fhJTzD4OTVoerhqOtkeWk=; b=lyoZtqRMQf0KSh1E6771IlhF4T RrLjV0QALpxuAPKkekpZyZQzp1pko+bePRoZZJZ8ieyVV9svFucFsTJJihcCgY79/+Ga4AHQJAc9s 0HjxA2m6YspkhDbzNJ8FksqryID1wx0o/FHYrZbeQAZmuJVCMo088yeeWEO0vm0Tt9I/3s7710GOE h1vZyqOcZojbUC8ClviRx150cBwXx7bgs0Stvn7e/Y74KTKUQD3jGgHsXsJfr8QvEdBTO4/qnlaWf rvTpv2se5FecitDGJbn+/YyKGUb7cbrew+LBJmByxqOXDXj2JzWyvd5zyQm4Qr4kt6qFg51hdkrIL K1f5k5Dw==; 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 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-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Headers-End: 1viZUu-0002nT-Ln Subject: Re: [f2fs-dev] [PATCH 00/29] fs: require filesystems to explicitly opt-in to nfsd export support X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Martin Brandenburg , jfs-discussion@lists.sourceforge.net, Jan Kara , Paulo Alcantara , Alex Markuze , Sandeep Dhavale , linux-btrfs@vger.kernel.org, Carlos Maiolino , Amir Goldstein , linux-unionfs@vger.kernel.org, Konstantin Komarov , Chris Mason , Andreas Dilger , Chunhai Guo , Ronnie Sahlberg , linux-mtd@lists.infradead.org, Mike Marshall , linux-xfs@vger.kernel.org, linux-nilfs@vger.kernel.org, Yue Hu , Miklos Szeredi , Richard Weinberger , Mark Fasheh , Hugh Dickins , Dai Ngo , Ryusuke Konishi , Christoph Hellwig , Viacheslav Dubeyko , NeilBrown , Gao Xiang , linux-ext4@vger.kernel.org, Salah Triki , linux-mm@kvack.org, devel@lists.orangefs.org, Shyam Prasad N , Olga Kornievskaia , linux-cifs@vger.kernel.org, Dave Kleikamp , linux-nfs@vger.kernel.org, Tom Talpey , ocfs2-devel@lists.linux.dev, Bharath SM , David Sterba , Alexander Viro , Baolin Wang , Jeffle Xu , Jaegeuk Kim , ceph-devel@vger.kernel.org, Ilya Dryomov , OGAWA Hirofumi , Andreas Gruenbacher , gfs2@lists.linux.dev, Christian Brauner , Theodore Ts'o , Luis de Bethencourt , Joseph Qi , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, Steve French , Chuck Lever , Hongbo Li , Anna Schumaker , Jan Kara , linux-fsdevel@vger.kernel.org, Phillip Lougher , Andrew Morton , ntfs3@lists.linux.dev, David Woodhouse , Trond Myklebust , Joel Becker Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel