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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6A3B4D3CC9F for ; Thu, 15 Jan 2026 08:14:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC6646B0088; Thu, 15 Jan 2026 03:14:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C49946B0089; Thu, 15 Jan 2026 03:14:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2B836B008A; Thu, 15 Jan 2026 03:14:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9E8FA6B0088 for ; Thu, 15 Jan 2026 03:14:33 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 48D6013A074 for ; Thu, 15 Jan 2026 08:14:33 +0000 (UTC) X-FDA: 84333486426.25.3330214 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf04.hostedemail.com (Postfix) with ESMTP id 8350740015 for ; Thu, 15 Jan 2026 08:14:31 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnbS2cfp; spf=pass (imf04.hostedemail.com: domain of brauner@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1768464871; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FXFHeU8QpH/lQamvGnH1b8chwcMeSz98NW19o+yr6yo=; b=vxBfjYlD6Fb1fyaQ9SScXNBc2b59Ma8pBR0zq2/KQ6G0Ctc2HbPP0931q2yV+SiUPQy5v9 cPc0AN0PziLmhJXcgEOyrllufRsJhQ3FjyQE5w54eAESZXLx4Tn+e4VIZWIOKXfde2Pm+G 8llu0U/PP0wUDMIExJptl00KFfu9eHk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=XnbS2cfp; spf=pass (imf04.hostedemail.com: domain of brauner@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1768464871; a=rsa-sha256; cv=none; b=PASiq2/EIi3nXHxv8UMr46FXpTa7Npv6GFBTK4kwMLgjgJxLCLNmgEgO3PdrKdamigPH7O 975CU+ZV5W8GJ3RYcuXwf0O1lvuii5oQ1TmV9J3d1BLfh3EtOpwIC8o76HspQ4Hqa4oLDM FnIspZfIHtvwAkW3xmwz0W+5hof5E10= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 3DB4B406A8; Thu, 15 Jan 2026 08:14:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64986C116D0; Thu, 15 Jan 2026 08:14:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768464870; bh=WiSNn2zvCUvnX3icYjakRozNqyZdq45DKgsu3cHWUEo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XnbS2cfpntTwX4GFJAoawDW2AeA5ZSsT+/PONrd75H6dIfGkNvM5vgeSHaOAPv8dM FrUnVk8caQ2ZgKDdkW59pGpZdLQn5pXMBsCnewkG8ZRPBAs5NmgswKQgR2jlXOGTLH 1XC97DnUwAHpyZvcxc/R/9ANrCDd89hPll0MVVz035TWRgfHi07Ohy3FXm8Oi6cHMd K1B5BtZtQ3crjd06l/WXb42A7DNOvPmKTEyhkbAB9zRLk0VcQ62qYkO65llb6ehby+ 4dGtOQAqLPZ8prbPHH4nyrrHNN5EkPlne7JgZK52gq0fyn0vzFLiAfA69H2k4JHDn4 iObH+Pt4IvcIg== Date: Thu, 15 Jan 2026 09:14:06 +0100 From: Christian Brauner To: Christoph Hellwig Cc: 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: <20260115-inspektion-kochbuch-505d8f94829e@brauner> References: <20260113-mondlicht-raven-82fc4eb70e9d@brauner> <20260114-klarstellen-blamieren-0b7d40182800@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: 9qomxwu9yf4jr9yuskxj9rbqqyzuexnj X-Rspamd-Queue-Id: 8350740015 X-Rspamd-Server: rspam04 X-HE-Tag: 1768464871-465351 X-HE-Meta: U2FsdGVkX1/TzqHp3LNaWsg9rCsFoS6/pGn+ujQNxi1IYvlq0ZRzQjxqJE/UUtaTPOCFQzawUfwa6sPZ+nhfMPruVb24aVAGaPrHYVLH7AYjJNo4x4zKNlMJafs/gqtKxBqlDNgZrxakh598y8n7Q50n/jpItRoC425jEivJmz1Oev9Uq2Sih+JY4HD9WVGr2rp/L55LwhalfaBSKaNZcZn0bzWyPJzLwf1lmKC39q2E+Cd6DtigWu6jujWrSA1bM/l1u88UksiKFr6OPxPi4p+wH9/dwjBCt4/j/2NWtopVqfo0dvN4ijHXZtRybaZC1KCdOmapNXn5gc0FdeGt4VVRwdiVp8RRfWICoUq1EsrkyyRRb/j3v1yjnZ/ZAtMjvfUVNc9YZv72PE7z1XIfgVKvKzyPGev5EaluT6DdpZkZJflv1pUgPu1Lne/leknjw/7OJDSn9rDCO2b87hMPrJ3I2Z2Ct1E1zAqk3+0fLkED9M5GVHaxsGrQnUcsRYSHVIw0gKFPD0Z5OK1bHLhPckyTFzxd6SHlCzUJS/kOfqGFsWAvkipuv7OHdYRUA9DVsQKOuv4LGHHoG3N5abfq8TazvE7tOm14gha3hh4utDq9uqTDLCJUWlri4DVKv5NoT+vaa1LxhOx5E5Jsjs+erZSHP1XHkRN/UJTKam7trNJrd+/8DvCXZqKCIU2rEXjuRMJonVCU55g0MeU4mW0z8yiZlJh3bx3mEiQJejZpA7Fl1aSZmaK5ufV8gwYk+byRxryOZUM9HG8AeMbiLThF0l7C821A4QeF7KzO6LCa4N40yGknIhNZVQr1iayW4cE/x4+QDxWUngH0VpFcEBBxbjwJCPZnZgFMZI0uFNUbnReVBKvmt3KZAj2PKAy/HgscvKPzK/nTwLfVrbD8+vGzpCMgRjPaHm2d7rOQCE5/KVfoIv9wm91YKJhv0+pK1XWK4ILjfakxfiYoYqDy2tP fofL2yTV o1ByxnWh3nf0vXpTYKJn5G4NiQvkyucfy1QW0LM5N7agRIfUkVu5Efun4oN3N8ebp2ifmy1cJitAJSt3C9zztKwPF3a0QJdjX+3owSQvSsOP77BUh9Vm++zxuvSXThhw+FeQIBLMrFIoNr+uG0qZw/TVWdAhHxbXjKph9cfHyuP8p4OfAZZx2BTuLqw3EjZUxImOpJBQvkFKTg0WlD6q+jecdpH1s41z6GbLwHlFNvdvAeYugQUflD27pGUIXy4yS7AgRZffCeNJ+oSrhiUVIVLnApD5x3rbTeS/9YRrlWoiIPtHBlcKvNO3PzyDWdkVW1bGJF8ryULOjmtA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jan 14, 2026 at 10:42:48PM -0800, Christoph Hellwig wrote: > 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). You're arguing for the sake of arguing imho. You're getting exactly what we're all saying as evidenced by the last paragraph in your mail: it is entirely what this whole thing is about. > 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. This is an entirely irrelevant point because we're talking about cgroupfs, nsfs, and pidfs. And they don't meet this criteria. cgroupfs is a _local resource management filesystem_ why would we ever want to support exporting it over the network. It allows to break the local delegation model as I've explained. cgroupfs shows _local processes_. So a server will see completely nonsensical PID identifiers listed in cgroup files and it can fsck around with processes in a remote system. Hard NAK. Entirely irrelevant if that filesystem meets the theoretical standards. > 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. We are all in agreement here.