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 2AC801A840A; Thu, 15 Jan 2026 06:43:23 +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=1768459406; cv=none; b=lDKP/qr1c/B2/t5f4JG8baXtGgDzNujepG/4zISjqyUv9WVr88Date+HbWTrjSRAbwMCR+P6+xopbF6iGlVPvZvJA+omzwgtLobPHGhxPudmaYusRCgvkdKmBg7iqL901+xpDNCDMNWY6QHmDffzNd1d99nyq+GFZPWCeSHmnbQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768459406; c=relaxed/simple; bh=TM8Ev/b3c/mRuEf1wSyVsat8A/pmVWNB0QddhAk6HhQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FzsuWjv6ZnqlXqIj+e4dGRkn2fdHhMSdFKdsxKZy7JLysigD4XjNuL2v5aeOZ0pDLiWuAEEHJyi7lyXF2YjMl6JdoIc1XQcy5LC7K+F72z3vphzwVeDK67WPKP9Q/QCfKu95VhOfbbOmBojVzPgjgCrrFI9LFIwO8zpMmqEQqhY= 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=VGObqK5v; 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="VGObqK5v" 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=/I/lmC8LP3DXdryYas7yQPVnLzGMCsU6bnNnqo9iZUY=; b=VGObqK5voCZEvaOS2sd8k58SOl 1MKXHul0UIxtbNustQjF3TiNBO5A5DEV+7luUQDjVEmdj1o6ZXj7/RHbsW5uQ8FHghSmNa8RGSf/Z lqXP7DBojYS/m9d+kpswr79pVrMANdI/lJ+/vLktuyA9+4LwMwmW4ZudctP5Nn8fgcUOpIxP4H3bZ wZU+Uv2sOpV/KHIJNeQwI3FUfk0W1FapF8T8lBqL+KFM3MrFgZ4F2CMZTLhz100xPKnoPJhHW7ms9 sJwJmQ51fc9hgVLMQHKjPH4dx2dyuUWDE38tPmbeAdELv7G3/fIrEXIlcOTJgefaGpHmCuyNcNjpw 8JLGu1tA==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vgH4C-0000000Brtc-23Ey; Thu, 15 Jan 2026 06:42:48 +0000 Date: Wed, 14 Jan 2026 22:42:48 -0800 From: Christoph Hellwig To: Christian Brauner Cc: Christoph Hellwig , Amir Goldstein , Jeff Layton , 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: References: <20260113-mondlicht-raven-82fc4eb70e9d@brauner> <20260114-klarstellen-blamieren-0b7d40182800@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: <20260114-klarstellen-blamieren-0b7d40182800@brauner> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Wed, Jan 14, 2026 at 04:20:13PM +0100, Christian Brauner wrote: > > You're still think of it the wrong way. If we do have file systems > > that break the original exportfs semantics we need to fix that, and > > something like a "stable handles" flag will work well for that. But > > a totally arbitrary "is exportable" flag is total nonsense. > > File handles can legitimately be conceptualized independently of > exporting a filesystem. If we wanted to tear those concepts apart > implementation wise we could. > > It is complete nonsense to expect the kernel to support exporting any > arbitrary internal filesystem or to not support file handles at all. You are going even further down the path of entirely missing the point (or the two points by now). If a file systems meets all technical requirements of being nfsd exportable and the users asks for it, it is not our job to make an arbitrary policy decision to say no. If it does not meet the technical requirements it obviously should not be exportable. And it seems like the spread of file handles beyond nfs exporting created some ambiguity here, which we need to fix.