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 1784ED2D117 for ; Tue, 13 Jan 2026 15:00:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6DE856B0089; Tue, 13 Jan 2026 10:00:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 68C276B008A; Tue, 13 Jan 2026 10:00:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 536976B008C; Tue, 13 Jan 2026 10:00:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 3BD076B0089 for ; Tue, 13 Jan 2026 10:00:26 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E8955C0770 for ; Tue, 13 Jan 2026 15:00:25 +0000 (UTC) X-FDA: 84327251610.23.0ED5E70 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf11.hostedemail.com (Postfix) with ESMTP id 7E3CB4001A for ; Tue, 13 Jan 2026 15:00:23 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Pti0579H; spf=pass (imf11.hostedemail.com: domain of jlayton@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=jlayton@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=1768316423; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iqWo6XEBsTZmTB1GOpVznVxe8jSHbPoaeo5HEoVAzxQ=; b=pm18rTHnUXHfnyfNCvL3jH2LIhQs6jfAyISi9sH3dWueE+1+yefzvuiCqKbXyT1V0/JOFW mH0qgWvRRAAStZCUBvdgoruxr6nUyjSoSg9L3g0sNekz1gB6TMrQuk4KhoDhV0TtgE25GU GrQHWzOlEgN+s/0nu26KkYURVJrTK7w= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Pti0579H; spf=pass (imf11.hostedemail.com: domain of jlayton@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=jlayton@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1768316423; a=rsa-sha256; cv=none; b=A3Kz5f017d8sojjNyyL66mX7GwwnCjxPAnYnzLivsbuMT0E6ltx+rojRD+EI04SwUWfo9T RXbmP+YQ6AvedsEm5HwM8LfRDKEFucfg+8exPD3pc3QGqDU20V49CzQXOWCVn9j5Yn90bq bjiHrcpo6imoy+bA+/11PYwfT2TWEtE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 1ED8544418; Tue, 13 Jan 2026 15:00:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C16CC4AF09; Tue, 13 Jan 2026 15:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768316422; bh=iqWo6XEBsTZmTB1GOpVznVxe8jSHbPoaeo5HEoVAzxQ=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Pti0579HtFWYiAekfRrKZQ06MXyTIIC1VoaIre/RaYMenLYb6j3rZgotfcylsoPkd +ThgsuvbmIi4xeo3BvoDpfqvBXFg02zNJrj0BC9QOnvFKj0eLJRCKiNP3rCjfbpFXd NcfQUmK0lTtPk1P2ZIhMNOkd3StSdcmExinQbOdWBQiREITV8EHyb4zzGu7pv28pm2 uHa89YkcQW1qJuHvZMRDCJ0ZOCaZ96u05hwYlf+n/Xmz0WtQpALJYgdDBOq/DrcY43 vd2eIifKUSzTmiPkzKXFo4FX7lTchVyy6zQFWYovMyD1fe6lfdPCr61A9mAoRKIavw TynH6bW50mkMQ== Message-ID: <0fa7b8f75104cb7c6c2df96bd763705b399e05dd.camel@kernel.org> Subject: Re: [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support From: Jeff Layton To: Chuck Lever , Christian Brauner , Amir Goldstein Cc: Jan Kara , Luis de Bethencourt , Salah Triki , Nicolas Pitre , Christoph Hellwig , 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 Date: Tue, 13 Jan 2026 10:00:13 -0500 In-Reply-To: <78a5971a-822b-4eb4-9c3d-9c1011c5b479@oracle.com> References: <20260108-setlease-6-20-v1-0-ea4dec9b67fa@kernel.org> <8af369636c32b868f83669c49aea708ca3b894ac.camel@kernel.org> <20260113-mondlicht-raven-82fc4eb70e9d@brauner> <4a38de737a64e9b32092ea1f8a25a61b33705034.camel@kernel.org> <5809690c-bc87-4e66-9604-3f3ee58e2902@oracle.com> <594043c04e431992f6585d7430b39cff2b770655.camel@kernel.org> <78a5971a-822b-4eb4-9c3d-9c1011c5b479@oracle.com> Autocrypt: addr=jlayton@kernel.org; prefer-encrypt=mutual; keydata=mQINBE6V0TwBEADXhJg7s8wFDwBMEvn0qyhAnzFLTOCHooMZyx7XO7dAiIhDSi7G1NPxw n8jdFUQMCR/GlpozMFlSFiZXiObE7sef9rTtM68ukUyZM4pJ9l0KjQNgDJ6Fr342Htkjxu/kFV1Wv egyjnSsFt7EGoDjdKqr1TS9syJYFjagYtvWk/UfHlW09X+jOh4vYtfX7iYSx/NfqV3W1D7EDi0PqV T2h6v8i8YqsATFPwO4nuiTmL6I40ZofxVd+9wdRI4Db8yUNA4ZSP2nqLcLtFjClYRBoJvRWvsv4lm 0OX6MYPtv76hka8lW4mnRmZqqx3UtfHX/hF/zH24Gj7A6sYKYLCU3YrI2Ogiu7/ksKcl7goQjpvtV YrOOI5VGLHge0awt7bhMCTM9KAfPc+xL/ZxAMVWd3NCk5SamL2cE99UWgtvNOIYU8m6EjTLhsj8sn VluJH0/RcxEeFbnSaswVChNSGa7mXJrTR22lRL6ZPjdMgS2Km90haWPRc8Wolcz07Y2se0xpGVLEQ cDEsvv5IMmeMe1/qLZ6NaVkNuL3WOXvxaVT9USW1+/SGipO2IpKJjeDZfehlB/kpfF24+RrK+seQf CBYyUE8QJpvTZyfUHNYldXlrjO6n5MdOempLqWpfOmcGkwnyNRBR46g/jf8KnPRwXs509yAqDB6sE LZH+yWr9LQZEwARAQABtCVKZWZmIExheXRvbiA8amxheXRvbkBwb29jaGllcmVkcy5uZXQ+iQI7BB MBAgAlAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCTpXWPAIZAQAKCRAADmhBGVaCFc65D/4 gBLNMHopQYgG/9RIM3kgFCCQV0pLv0hcg1cjr+bPI5f1PzJoOVi9s0wBDHwp8+vtHgYhM54yt43uI 7Htij0RHFL5eFqoVT4TSfAg2qlvNemJEOY0e4daljjmZM7UtmpGs9NN0r9r50W82eb5Kw5bc/r0km R/arUS2st+ecRsCnwAOj6HiURwIgfDMHGPtSkoPpu3DDp/cjcYUg3HaOJuTjtGHFH963B+f+hyQ2B rQZBBE76ErgTDJ2Db9Ey0kw7VEZ4I2nnVUY9B5dE2pJFVO5HJBMp30fUGKvwaKqYCU2iAKxdmJXRI ONb7dSde8LqZahuunPDMZyMA5+mkQl7kpIpR6kVDIiqmxzRuPeiMP7O2FCUlS2DnJnRVrHmCljLkZ Wf7ZUA22wJpepBligemtSRSbqCyZ3B48zJ8g5B8xLEntPo/NknSJaYRvfEQqGxgk5kkNWMIMDkfQO lDSXZvoxqU9wFH/9jTv1/6p8dHeGM0BsbBLMqQaqnWiVt5mG92E1zkOW69LnoozE6Le+12DsNW7Rj iR5K+27MObjXEYIW7FIvNN/TQ6U1EOsdxwB8o//Yfc3p2QqPr5uS93SDDan5ehH59BnHpguTc27Xi QQZ9EGiieCUx6Zh2ze3X2UW9YNzE15uKwkkuEIj60NvQRmEDfweYfOfPVOueC+iFifbQgSmVmZiBM YXl0b24gPGpsYXl0b25AcmVkaGF0LmNvbT6JAjgEEwECACIFAk6V0q0CGwMGCwkIBwMCBhUIAgkKC wQWAgMBAh4BAheAAAoJEAAOaEEZVoIViKUQALpvsacTMWWOd7SlPFzIYy2/fjvKlfB/Xs4YdNcf9q LqF+lk2RBUHdR/dGwZpvw/OLmnZ8TryDo2zXVJNWEEUFNc7wQpl3i78r6UU/GUY/RQmOgPhs3epQC 3PMJj4xFx+VuVcf/MXgDDdBUHaCTT793hyBeDbQuciARDJAW24Q1RCmjcwWIV/pgrlFa4lAXsmhoa c8UPc82Ijrs6ivlTweFf16VBc4nSLX5FB3ls7S5noRhm5/Zsd4PGPgIHgCZcPgkAnU1S/A/rSqf3F LpU+CbVBDvlVAnOq9gfNF+QiTlOHdZVIe4gEYAU3CUjbleywQqV02BKxPVM0C5/oVjMVx3bri75n1 TkBYGmqAXy9usCkHIsG5CBHmphv9MHmqMZQVsxvCzfnI5IO1+7MoloeeW/lxuyd0pU88dZsV/riHw 87i2GJUJtVlMl5IGBNFpqoNUoqmvRfEMeXhy/kUX4Xc03I1coZIgmwLmCSXwx9MaCPFzV/dOOrju2 xjO+2sYyB5BNtxRqUEyXglpujFZqJxxau7E0eXoYgoY9gtFGsspzFkVNntamVXEWVVgzJJr/EWW0y +jNd54MfPRqH+eCGuqlnNLktSAVz1MvVRY1dxUltSlDZT7P2bUoMorIPu8p7ZCg9dyX1+9T6Muc5d Hxf/BBP/ir+3e8JTFQBFOiLNdFtB9KZWZmIExheXRvbiA8amxheXRvbkBzYW1iYS5vcmc+iQI4BBM BAgAiBQJOldK9AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAADmhBGVaCFWgWD/0ZRi4h N9FK2BdQs9RwNnFZUr7JidAWfCrs37XrA/56olQl3ojn0fQtrP4DbTmCuh0SfMijB24psy1GnkPep naQ6VRf7Dxg/Y8muZELSOtsv2CKt3/02J1BBitrkkqmHyni5fLLYYg6fub0T/8Kwo1qGPdu1hx2BQ RERYtQ/S5d/T0cACdlzi6w8rs5f09hU9Tu4qV1JLKmBTgUWKN969HPRkxiojLQziHVyM/weR5Reu6 FZVNuVBGqBD+sfk/c98VJHjsQhYJijcsmgMb1NohAzwrBKcSGKOWJToGEO/1RkIN8tqGnYNp2G+aR 685D0chgTl1WzPRM6mFG1+n2b2RR95DxumKVpwBwdLPoCkI24JkeDJ7lXSe3uFWISstFGt0HL8Eew P8RuGC8s5h7Ct91HMNQTbjgA+Vi1foWUVXpEintAKgoywaIDlJfTZIl6Ew8ETN/7DLy8bXYgq0Xzh aKg3CnOUuGQV5/nl4OAX/3jocT5Cz/OtAiNYj5mLPeL5z2ZszjoCAH6caqsF2oLyAnLqRgDgR+wTQ T6gMhr2IRsl+cp8gPHBwQ4uZMb+X00c/Amm9VfviT+BI7B66cnC7Zv6Gvmtu2rEjWDGWPqUgccB7h dMKnKDthkA227/82tYoFiFMb/NwtgGrn5n2vwJyKN6SEoygGrNt0SI84y6hEVbQlSmVmZiBMYXl0b 24gPGpsYXl0b25AcHJpbWFyeWRhdGEuY29tPokCOQQTAQIAIwUCU4xmKQIbAwcLCQgHAwIBBhUIAg kKCwQWAgMBAh4BAheAAAoJEAAOaEEZVoIV1H0P/j4OUTwFd7BBbpoSp695qb6HqCzWMuExsp8nZjr uymMaeZbGr3OWMNEXRI1FWNHMtcMHWLP/RaDqCJil28proO+PQ/yPhsr2QqJcW4nr91tBrv/MqItu AXLYlsgXqp4BxLP67bzRJ1Bd2x0bWXurpEXY//VBOLnODqThGEcL7jouwjmnRh9FTKZfBDpFRaEfD FOXIfAkMKBa/c9TQwRpx2DPsl3eFWVCNuNGKeGsirLqCxUg5kWTxEorROppz9oU4HPicL6rRH22Ce 6nOAON2vHvhkUuO3GbffhrcsPD4DaYup4ic+DxWm+DaSSRJ+e1yJvwi6NmQ9P9UAuLG93S2MdNNbo sZ9P8k2mTOVKMc+GooI9Ve/vH8unwitwo7ORMVXhJeU6Q0X7zf3SjwDq2lBhn1DSuTsn2DbsNTiDv qrAaCvbsTsw+SZRwF85eG67eAwouYk+dnKmp1q57LDKMyzysij2oDKbcBlwB/TeX16p8+LxECv51a sjS9TInnipssssUDrHIvoTTXWcz7Y5wIngxDFwT8rPY3EggzLGfK5Zx2Q5S/N0FfmADmKknG/D8qG IcJE574D956tiUDKN4I+/g125ORR1v7bP+OIaayAvq17RP+qcAqkxc0x8iCYVCYDouDyNvWPGRhbL UO7mlBpjW9jK9e2fvZY9iw3QzIPGKtClKZWZmIExheXRvbiA8amVmZi5sYXl0b25AcHJpbWFyeWRh dGEuY29tPokCOQQTAQIAIwUCU4xmUAIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEAAOa EEZVoIVzJoQALFCS6n/FHQS+hIzHIb56JbokhK0AFqoLVzLKzrnaeXhE5isWcVg0eoV2oTScIwUSU apy94if69tnUo4Q7YNt8/6yFM6hwZAxFjOXR0ciGE3Q+Z1zi49Ox51yjGMQGxlakV9ep4sV/d5a50 M+LFTmYSAFp6HY23JN9PkjVJC4PUv5DYRbOZ6Y1+TfXKBAewMVqtwT1Y+LPlfmI8dbbbuUX/kKZ5d dhV2736fgyfpslvJKYl0YifUOVy4D1G/oSycyHkJG78OvX4JKcf2kKzVvg7/Rnv+AueCfFQ6nGwPn 0P91I7TEOC4XfZ6a1K3uTp4fPPs1Wn75X7K8lzJP/p8lme40uqwAyBjk+IA5VGd+CVRiyJTpGZwA0 jwSYLyXboX+Dqm9pSYzmC9+/AE7lIgpWj+3iNisp1SWtHc4pdtQ5EU2SEz8yKvDbD0lNDbv4ljI7e flPsvN6vOrxz24mCliEco5DwhpaaSnzWnbAPXhQDWb/lUgs/JNk8dtwmvWnqCwRqElMLVisAbJmC0 BhZ/Ab4sph3EaiZfdXKhiQqSGdK4La3OTJOJYZphPdGgnkvDV9Pl1QZ0ijXQrVIy3zd6VCNaKYq7B AKidn5g/2Q8oio9Tf4XfdZ9dtwcB+bwDJFgvvDYaZ5bI3ln4V3EyW5i2NfXazz/GA/I/ZtbsigCFc 8ftCBKZWZmIExheXRvbiA8amxheXRvbkBrZXJuZWwub3JnPokCOAQTAQIAIgUCWe8u6AIbAwYLCQg HAwIGFQgCCQoLBBYCAwECHgECF4AACgkQAA5oQRlWghUuCg/+Lb/xGxZD2Q1oJVAE37uW308UpVSD 2tAMJUvFTdDbfe3zKlPDTuVsyNsALBGclPLagJ5ZTP+Vp2irAN9uwBuacBOTtmOdz4ZN2tdvNgozz uxp4CHBDVzAslUi2idy+xpsp47DWPxYFIRP3M8QG/aNW052LaPc0cedYxp8+9eiVUNpxF4SiU4i9J DfX/sn9XcfoVZIxMpCRE750zvJvcCUz9HojsrMQ1NFc7MFT1z3MOW2/RlzPcog7xvR5ENPH19ojRD CHqumUHRry+RF0lH00clzX/W8OrQJZtoBPXv9ahka/Vp7kEulcBJr1cH5Wz/WprhsIM7U9pse1f1g Yy9YbXtWctUz8uvDR7shsQxAhX3qO7DilMtuGo1v97I/Kx4gXQ52syh/w6EBny71CZrOgD6kJwPVV AaM1LRC28muq91WCFhs/nzHozpbzcheyGtMUI2Ao4K6mnY+3zIuXPygZMFr9KXE6fF7HzKxKuZMJO aEZCiDOq0anx6FmOzs5E6Jqdpo/mtI8beK+BE7Va6ni7YrQlnT0i3vaTVMTiCThbqsB20VrbMjlhp f8lfK1XVNbRq/R7GZ9zHESlsa35ha60yd/j3pu5hT2xyy8krV8vGhHvnJ1XRMJBAB/UYb6FyC7S+m QZIQXVeAA+smfTT0tDrisj1U5x6ZB9b3nBg65kc= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) MIME-Version: 1.0 X-Rspamd-Queue-Id: 7E3CB4001A X-Stat-Signature: jkxkrrnrk78jeei8htt1hupdccudby88 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1768316423-647216 X-HE-Meta: U2FsdGVkX1+wfs3e5ER17wSltaidKB1O82+VY3HJIRFXRg/a7nZrQYpTX3KLiZZQ33GrEHHEzWaYmQWEyG2X7hAsdvzLb0hn2ajx5FFAlIxtVNxDH17n0jZ8or0HRrfPtBaGpXxOzFaayznIKV3N9GYS+KnFlZNZ/49DCI8jG6bKMdhNBIblc5Nz8YGOkm4B4yS6E+0gXikqJNZwtuiHfWiHIm/02xR36G6jFhmUucY9UDOkSVesmlY9VshCQSZWGhsn6/JhogU3tL60ahc3TfIZVt8UF2+2MwF32aHQyGa/q9h0jy7un7tLdPfL76RxwNYDN3Nfcibd1n5eX+eguxRs3a8joPTKEU39PaalMs1bIOLfuZRpIRqVlksqNhC4IYEnNrFNLouR6dp73AjUMCOBjMxC6W1O2V7TFiuMdJekY0TYvatyJBm4iKSgwJgR45BkYZQ7f3KeKwKmd8cGGSOjeZHOibu6b6jwYQdny6OevRJ57OqviRU7r1+qoHc9Ph0UxCSkYVG0TPklJZRqjpmtKNVmONqdTjKW0plzq5l3XOoaj/6O5C31AU8FfWKFaSSyJi3uQdmtWom8e8q8xl0pD3WAFVV9Ob2tTxWHXta6BUf27HN7hq59cvJxBKYBGemyh1DuhJ03AELf80rIGFhtV9YwarIJg09KtGmNskXRBo/KuLluDTxYxjH+CgjKJ4UM5d2CU3flWklVbevkuPw08Bb8tmxMI6IQKQo7Jk2Dy7DPARX4mI8d/5/g1H956KNxBbULTBKxKgsBEbCANVkuPVUIbLflzgPKATfXDVhLU5tfLOnq5hnzAt3VeupafmldHO6Z9CbQK5XtaBlMsc5ZG9MKhoTQxKOYmu1Ggz52hGKuHJJgb4hIHoHURQhtCxoSQgdqrv6RzwuGnEe3kAjD9K79FATWYS9xTBoMvsIHLz9OcCwvpMOwaSEDtK/bNPAr+78fbp7mvnoB8V3 ZmhcVu/z jv41/QfBdQUDB6mQIhdq2BzES/hQCwdzrdUZmjBW7JWWMmlYGMeyZcPvQWXOxaTDH4l8Z3UWdCxzone79Av4PeRgOP36gms6Vd1t6glQTy+OWlZyl/NRSQqU+pP7thx+Pz11EeA2PXfkn3a5TTYl891RvOUJwLzhigtGeZcUsTHNWljjPh455zoBbjchLt7asXlmc3CVSFKa6jFoKAZWo6GRllm8GbDG0IoHbMFlxtATlseoKNZErQds0MDThx9lYTnPdDmLQ/yD865U5Y/sEXw53REMbyWRkqMBmjqMiqXvuGwf5wsGybftiWoP1BNARGr+p 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 Tue, 2026-01-13 at 09:31 -0500, Chuck Lever wrote: > On 1/13/26 9:27 AM, Jeff Layton wrote: > > On Tue, 2026-01-13 at 09:03 -0500, Chuck Lever wrote: > > > On 1/13/26 6:45 AM, Jeff Layton wrote: > > > > On Tue, 2026-01-13 at 09:54 +0100, Christian Brauner wrote: > > > > > On Mon, Jan 12, 2026 at 09:50:20AM -0500, Jeff Layton wrote: > > > > > > On Mon, 2026-01-12 at 09:31 -0500, Chuck Lever wrote: > > > > > > > On 1/12/26 8:34 AM, Jeff Layton wrote: > > > > > > > > On Fri, 2026-01-09 at 19:52 +0100, Amir Goldstein wrote: > > > > > > > > > On Thu, Jan 8, 2026 at 7:57=E2=80=AFPM Jeff Layton wrote: > > > > > > > > > >=20 > > > > > > > > > > On Thu, 2026-01-08 at 18:40 +0100, Jan Kara wrote: > > > > > > > > > > > On Thu 08-01-26 12:12:55, Jeff Layton wrote: > > > > > > > > > > > > Yesterday, I sent patches to fix how directory dele= gation support is > > > > > > > > > > > > handled on filesystems where the should be disabled= [1]. That set is > > > > > > > > > > > > appropriate for v6.19. For v7.0, I want to make lea= se support be more > > > > > > > > > > > > opt-in, rather than opt-out: > > > > > > > > > > > >=20 > > > > > > > > > > > > For historical reasons, when ->setlease() file_oper= ation is set to NULL, > > > > > > > > > > > > the default is to use the kernel-internal lease imp= lementation. This > > > > > > > > > > > > means that if you want to disable them, you need to= explicitly set the > > > > > > > > > > > > ->setlease() file_operation to simple_nosetlease() = or the equivalent. > > > > > > > > > > > >=20 > > > > > > > > > > > > This has caused a number of problems over the years= as some filesystems > > > > > > > > > > > > have inadvertantly allowed leases to be acquired si= mply by having left > > > > > > > > > > > > it set to NULL. It would be better if filesystems h= ad to opt-in to lease > > > > > > > > > > > > support, particularly with the advent of directory = delegations. > > > > > > > > > > > >=20 > > > > > > > > > > > > This series has sets the ->setlease() operation in = a pile of existing > > > > > > > > > > > > local filesystems to generic_setlease() and then ch= anges > > > > > > > > > > > > kernel_setlease() to return -EINVAL when the setlea= se() operation is not > > > > > > > > > > > > set. > > > > > > > > > > > >=20 > > > > > > > > > > > > With this change, new filesystems will need to expl= icitly set the > > > > > > > > > > > > ->setlease() operations in order to provide lease a= nd delegation > > > > > > > > > > > > support. > > > > > > > > > > > >=20 > > > > > > > > > > > > I mainly focused on filesystems that are NFS export= able, since NFS and > > > > > > > > > > > > SMB are the main users of file leases, and they ten= d to end up exporting > > > > > > > > > > > > the same filesystem types. Let me know if I've miss= ed any. > > > > > > > > > > >=20 > > > > > > > > > > > So, what about kernfs and fuse? They seem to be expor= table and don't have > > > > > > > > > > > .setlease set... > > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > Yes, FUSE needs this too. I'll add a patch for that. > > > > > > > > > >=20 > > > > > > > > > > As far as kernfs goes: AIUI, that's basically what sysf= s and resctrl > > > > > > > > > > are built on. Do we really expect people to set leases = there? > > > > > > > > > >=20 > > > > > > > > > > I guess it's technically a regression since you could s= et them on those > > > > > > > > > > sorts of files earlier, but people don't usually export= kernfs based > > > > > > > > > > filesystems via NFS or SMB, and that seems like somethi= ng that could be > > > > > > > > > > used to make mischief. > > > > > > > > > >=20 > > > > > > > > > > AFAICT, kernfs_export_ops is mostly to support open_by_= handle_at(). See > > > > > > > > > > commit aa8188253474 ("kernfs: add exportfs operations")= . > > > > > > > > > >=20 > > > > > > > > > > One idea: we could add a wrapper around generic_setleas= e() for > > > > > > > > > > filesystems like this that will do a WARN_ONCE() and th= en call > > > > > > > > > > generic_setlease(). That would keep leases working on t= hem but we might > > > > > > > > > > get some reports that would tell us who's setting lease= s on these files > > > > > > > > > > and why. > > > > > > > > >=20 > > > > > > > > > IMO, you are being too cautious, but whatever. > > > > > > > > >=20 > > > > > > > > > It is not accurate that kernfs filesystems are NFS export= able in general. > > > > > > > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP. > > > > > > > > >=20 > > > > > > > > > If any application is using leases on cgroup files, it mu= st be some > > > > > > > > > very advanced runtime (i.e. systemd), so we should know a= bout the > > > > > > > > > regression sooner rather than later. > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > I think so too. For now, I think I'll not bother with the W= ARN_ONCE(). > > > > > > > > Let's just leave kernfs out of the set until someone presen= ts a real > > > > > > > > use-case. > > > > > > > >=20 > > > > > > > > > There are also the recently added nsfs and pidfs export_o= perations. > > > > > > > > >=20 > > > > > > > > > I have a recollection about wanting to be explicit about = not allowing > > > > > > > > > those to be exportable to NFS (nsfs specifically), but I = can't see where > > > > > > > > > and if that restriction was done. > > > > > > > > >=20 > > > > > > > > > Christian? Do you remember? > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > (cc'ing Chuck) > > > > > > > >=20 > > > > > > > > FWIW, you can currently export and mount /sys/fs/cgroup via= NFS. The > > > > > > > > directory doesn't show up when you try to get to it via NFS= v4, but you > > > > > > > > can mount it using v3 and READDIR works. The files are all = empty when > > > > > > > > you try to read them. I didn't try to do any writes. > > > > > > > >=20 > > > > > > > > Should we add a mechanism to prevent exporting these sorts = of > > > > > > > > filesystems? > > > > > > > >=20 > > > > > > > > Even better would be to make nfsd exporting explicitly opt-= in. What if > > > > > > > > we were to add a EXPORT_OP_NFSD flag that explicitly allows= filesystems > > > > > > > > to opt-in to NFS exporting, and check for that in __fh_veri= fy()? We'd > > > > > > > > have to add it to a bunch of existing filesystems, but that= 's fairly > > > > > > > > simple to do with an LLM. > > > > > > >=20 > > > > > > > What's the active harm in exporting /sys/fs/cgroup ? It has t= o be done > > > > > > > explicitly via /etc/exports, so this is under the NFS server = admin's > > > > > > > control. Is it an attack surface? > > > > > > >=20 > > > > > >=20 > > > > > > Potentially? > > > > > >=20 > > > > > > I don't see any active harm with exporting cgroupfs. It doesn't= work > > > > > > right via nfsd, but it's not crashing the box or anything. > > > > > >=20 > > > > > > At one time, those were only defined by filesystems that wanted= to > > > > > > allow NFS export. Now we've grown them on filesystems that just= want to > > > > > > provide filehandles for open_by_handle_at() and the like. nfsd = doesn't > > > > > > care though: if the fs has export operations, it'll happily use= them. > > > > > >=20 > > > > > > Having an explicit "I want to allow nfsd" flag see ms like it m= ight > > > > > > save us some headaches in the future when other filesystems add= export > > > > > > ops for this sort of filehandle use. > > > > >=20 > > > > > So we are re-hashing a discussion we had a few months ago (Amir w= as > > > > > involved at least). > > > > >=20 > > > >=20 > > > > Yep, I was lurking on it, but didn't have a lot of input at the tim= e. > > > >=20 > > > > > I don't think we want to expose cgroupfs via NFS that's super wei= rd. > > > > > It's like remote partial resource management and it would be very > > > > > strange if a remote process suddenly would be able to move things= around > > > > > in the cgroup tree. So I would prefer to not do this. > > > > >=20 > > > > > So my preference would be to really sever file handles from the e= xport > > > > > mechanism so that we can allow stuff like pidfs and nsfs and cgro= upfs to > > > > > use file handles via name_to_handle_at() and open_by_handle_at() = without > > > > > making them exportable. > > > >=20 > > > > Agreed. I think we want to make NFS export be a deliberate opt-in > > > > decision that filesystem developers make. > > >=20 > > > No objection, what about ksmbd, AFS, or Ceph? > > >=20 > >=20 > > ksmbd doesn't have anything akin to an export_operations. I think it > > really has to rely on admins getting the share paths right when > > exporting. This is a bit simpler there though since SMB2 doesn't deal > > with filehandles. > >=20 > > AFS and Ceph in the kernel are clients. AFS isn't reexportable via NFS, > > but Ceph is. We'll need to preserve that ability. >=20 > Well I think my point is that "is this file system type exportable" > might be orthogonal to whether the FS offers a filehandle capability. If > it doesn't make sense to export cgroupfs via NFS, it probably also does > not make sense for ksmbd. Lather, rinse, repeat for other in-kernel file > servers. >=20 > Perhaps the "is_exportable" predicate is better placed separately from > export_ops. >=20 That's a fair point. An fstype flag would seem most natural then. For nfsd, I guess we'd want to check for that in fh_compose() and fh_verify() ? I don't know ksmbd well enough to know how they would want to plumb in a check for this though. Maybe at the point where they resolve pathnames? --=20 Jeff Layton