Documentation/filesystems/porting.rst | 9 +++++++++ Documentation/filesystems/vfs.rst | 9 ++++++--- fs/9p/vfs_dir.c | 2 -- fs/9p/vfs_file.c | 2 -- fs/affs/dir.c | 2 ++ fs/affs/file.c | 2 ++ fs/befs/linuxvfs.c | 2 ++ fs/btrfs/file.c | 2 ++ fs/btrfs/inode.c | 2 ++ fs/ceph/dir.c | 2 -- fs/ceph/file.c | 1 - fs/cramfs/inode.c | 2 ++ fs/efs/dir.c | 2 ++ fs/erofs/data.c | 2 ++ fs/erofs/dir.c | 2 ++ fs/exfat/dir.c | 2 ++ fs/exfat/file.c | 2 ++ fs/ext2/dir.c | 2 ++ fs/ext2/file.c | 2 ++ fs/ext4/dir.c | 2 ++ fs/ext4/file.c | 2 ++ fs/f2fs/dir.c | 2 ++ fs/f2fs/file.c | 2 ++ fs/fat/dir.c | 2 ++ fs/fat/file.c | 2 ++ fs/freevxfs/vxfs_lookup.c | 2 ++ fs/fuse/dir.c | 1 - fs/gfs2/file.c | 3 +-- fs/isofs/dir.c | 2 ++ fs/jffs2/dir.c | 2 ++ fs/jffs2/file.c | 2 ++ fs/jfs/file.c | 2 ++ fs/jfs/namei.c | 2 ++ fs/libfs.c | 20 ++------------------ fs/locks.c | 3 +-- fs/nfs/dir.c | 1 - fs/nfs/file.c | 1 - fs/nilfs2/dir.c | 3 ++- fs/nilfs2/file.c | 2 ++ fs/ntfs3/dir.c | 3 +++ fs/ntfs3/file.c | 3 +++ fs/ocfs2/file.c | 5 +++++ fs/orangefs/dir.c | 4 +++- fs/orangefs/file.c | 1 + fs/overlayfs/file.c | 2 ++ fs/overlayfs/readdir.c | 2 ++ fs/qnx4/dir.c | 2 ++ fs/qnx6/dir.c | 2 ++ fs/read_write.c | 2 ++ fs/smb/client/cifsfs.c | 1 - fs/squashfs/dir.c | 2 ++ fs/squashfs/file.c | 4 +++- fs/udf/dir.c | 2 ++ fs/udf/file.c | 2 ++ fs/ufs/dir.c | 2 ++ fs/ufs/file.c | 2 ++ fs/vboxsf/dir.c | 1 - fs/vboxsf/file.c | 1 - fs/xfs/xfs_file.c | 3 +++ include/linux/fs.h | 1 - mm/shmem.c | 2 ++ 61 files changed, 116 insertions(+), 42 deletions(-)
Yesterday, I sent patches to fix how directory delegation 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 lease support be more
opt-in, rather than opt-out:
For historical reasons, when ->setlease() file_operation is set to NULL,
the default is to use the kernel-internal lease implementation. This
means that if you want to disable them, you need to explicitly set the
->setlease() file_operation to simple_nosetlease() or the equivalent.
This has caused a number of problems over the years as some filesystems
have inadvertantly allowed leases to be acquired simply by having left
it set to NULL. It would be better if filesystems had to opt-in to lease
support, particularly with the advent of directory delegations.
This series has sets the ->setlease() operation in a pile of existing
local filesystems to generic_setlease() and then changes
kernel_setlease() to return -EINVAL when the setlease() operation is not
set.
With this change, new filesystems will need to explicitly set the
->setlease() operations in order to provide lease and delegation
support.
I mainly focused on filesystems that are NFS exportable, since NFS and
SMB are the main users of file leases, and they tend to end up exporting
the same filesystem types. Let me know if I've missed any.
[1]: https://lore.kernel.org/linux-fsdevel/20260107-setlease-6-19-v1-0-85f034abcc57@kernel.org/
Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Jeff Layton (24):
fs: add setlease to generic_ro_fops and read-only filesystem directory operations
affs: add setlease file operation
btrfs: add setlease file operation
erofs: add setlease file operation
ext2: add setlease file operation
ext4: add setlease file operation
exfat: add setlease file operation
f2fs: add setlease file operation
fat: add setlease file operation
gfs2: add a setlease file operation
jffs2: add setlease file operation
jfs: add setlease file operation
nilfs2: add setlease file operation
ntfs3: add setlease file operation
ocfs2: add setlease file operation
orangefs: add setlease file operation
overlayfs: add setlease file operation
squashfs: add setlease file operation
tmpfs: add setlease file operation
udf: add setlease file operation
ufs: add setlease file operation
xfs: add setlease file operation
filelock: default to returning -EINVAL when ->setlease operation is NULL
fs: remove simple_nosetlease()
Documentation/filesystems/porting.rst | 9 +++++++++
Documentation/filesystems/vfs.rst | 9 ++++++---
fs/9p/vfs_dir.c | 2 --
fs/9p/vfs_file.c | 2 --
fs/affs/dir.c | 2 ++
fs/affs/file.c | 2 ++
fs/befs/linuxvfs.c | 2 ++
fs/btrfs/file.c | 2 ++
fs/btrfs/inode.c | 2 ++
fs/ceph/dir.c | 2 --
fs/ceph/file.c | 1 -
fs/cramfs/inode.c | 2 ++
fs/efs/dir.c | 2 ++
fs/erofs/data.c | 2 ++
fs/erofs/dir.c | 2 ++
fs/exfat/dir.c | 2 ++
fs/exfat/file.c | 2 ++
fs/ext2/dir.c | 2 ++
fs/ext2/file.c | 2 ++
fs/ext4/dir.c | 2 ++
fs/ext4/file.c | 2 ++
fs/f2fs/dir.c | 2 ++
fs/f2fs/file.c | 2 ++
fs/fat/dir.c | 2 ++
fs/fat/file.c | 2 ++
fs/freevxfs/vxfs_lookup.c | 2 ++
fs/fuse/dir.c | 1 -
fs/gfs2/file.c | 3 +--
fs/isofs/dir.c | 2 ++
fs/jffs2/dir.c | 2 ++
fs/jffs2/file.c | 2 ++
fs/jfs/file.c | 2 ++
fs/jfs/namei.c | 2 ++
fs/libfs.c | 20 ++------------------
fs/locks.c | 3 +--
fs/nfs/dir.c | 1 -
fs/nfs/file.c | 1 -
fs/nilfs2/dir.c | 3 ++-
fs/nilfs2/file.c | 2 ++
fs/ntfs3/dir.c | 3 +++
fs/ntfs3/file.c | 3 +++
fs/ocfs2/file.c | 5 +++++
fs/orangefs/dir.c | 4 +++-
fs/orangefs/file.c | 1 +
fs/overlayfs/file.c | 2 ++
fs/overlayfs/readdir.c | 2 ++
fs/qnx4/dir.c | 2 ++
fs/qnx6/dir.c | 2 ++
fs/read_write.c | 2 ++
fs/smb/client/cifsfs.c | 1 -
fs/squashfs/dir.c | 2 ++
fs/squashfs/file.c | 4 +++-
fs/udf/dir.c | 2 ++
fs/udf/file.c | 2 ++
fs/ufs/dir.c | 2 ++
fs/ufs/file.c | 2 ++
fs/vboxsf/dir.c | 1 -
fs/vboxsf/file.c | 1 -
fs/xfs/xfs_file.c | 3 +++
include/linux/fs.h | 1 -
mm/shmem.c | 2 ++
61 files changed, 116 insertions(+), 42 deletions(-)
---
base-commit: 731ce71a6c8adb8b8f873643beacaeedc1564500
change-id: 20260107-setlease-6-20-299eb5695c5a
Best regards,
--
Jeff Layton <jlayton@kernel.org>
On Thu 08-01-26 12:12:55, Jeff Layton wrote: > Yesterday, I sent patches to fix how directory delegation 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 lease support be more > opt-in, rather than opt-out: > > For historical reasons, when ->setlease() file_operation is set to NULL, > the default is to use the kernel-internal lease implementation. This > means that if you want to disable them, you need to explicitly set the > ->setlease() file_operation to simple_nosetlease() or the equivalent. > > This has caused a number of problems over the years as some filesystems > have inadvertantly allowed leases to be acquired simply by having left > it set to NULL. It would be better if filesystems had to opt-in to lease > support, particularly with the advent of directory delegations. > > This series has sets the ->setlease() operation in a pile of existing > local filesystems to generic_setlease() and then changes > kernel_setlease() to return -EINVAL when the setlease() operation is not > set. > > With this change, new filesystems will need to explicitly set the > ->setlease() operations in order to provide lease and delegation > support. > > I mainly focused on filesystems that are NFS exportable, since NFS and > SMB are the main users of file leases, and they tend to end up exporting > the same filesystem types. Let me know if I've missed any. So, what about kernfs and fuse? They seem to be exportable and don't have .setlease set... Honza > > [1]: https://lore.kernel.org/linux-fsdevel/20260107-setlease-6-19-v1-0-85f034abcc57@kernel.org/ > > Signed-off-by: Jeff Layton <jlayton@kernel.org> > --- > Jeff Layton (24): > fs: add setlease to generic_ro_fops and read-only filesystem directory operations > affs: add setlease file operation > btrfs: add setlease file operation > erofs: add setlease file operation > ext2: add setlease file operation > ext4: add setlease file operation > exfat: add setlease file operation > f2fs: add setlease file operation > fat: add setlease file operation > gfs2: add a setlease file operation > jffs2: add setlease file operation > jfs: add setlease file operation > nilfs2: add setlease file operation > ntfs3: add setlease file operation > ocfs2: add setlease file operation > orangefs: add setlease file operation > overlayfs: add setlease file operation > squashfs: add setlease file operation > tmpfs: add setlease file operation > udf: add setlease file operation > ufs: add setlease file operation > xfs: add setlease file operation > filelock: default to returning -EINVAL when ->setlease operation is NULL > fs: remove simple_nosetlease() > > Documentation/filesystems/porting.rst | 9 +++++++++ > Documentation/filesystems/vfs.rst | 9 ++++++--- > fs/9p/vfs_dir.c | 2 -- > fs/9p/vfs_file.c | 2 -- > fs/affs/dir.c | 2 ++ > fs/affs/file.c | 2 ++ > fs/befs/linuxvfs.c | 2 ++ > fs/btrfs/file.c | 2 ++ > fs/btrfs/inode.c | 2 ++ > fs/ceph/dir.c | 2 -- > fs/ceph/file.c | 1 - > fs/cramfs/inode.c | 2 ++ > fs/efs/dir.c | 2 ++ > fs/erofs/data.c | 2 ++ > fs/erofs/dir.c | 2 ++ > fs/exfat/dir.c | 2 ++ > fs/exfat/file.c | 2 ++ > fs/ext2/dir.c | 2 ++ > fs/ext2/file.c | 2 ++ > fs/ext4/dir.c | 2 ++ > fs/ext4/file.c | 2 ++ > fs/f2fs/dir.c | 2 ++ > fs/f2fs/file.c | 2 ++ > fs/fat/dir.c | 2 ++ > fs/fat/file.c | 2 ++ > fs/freevxfs/vxfs_lookup.c | 2 ++ > fs/fuse/dir.c | 1 - > fs/gfs2/file.c | 3 +-- > fs/isofs/dir.c | 2 ++ > fs/jffs2/dir.c | 2 ++ > fs/jffs2/file.c | 2 ++ > fs/jfs/file.c | 2 ++ > fs/jfs/namei.c | 2 ++ > fs/libfs.c | 20 ++------------------ > fs/locks.c | 3 +-- > fs/nfs/dir.c | 1 - > fs/nfs/file.c | 1 - > fs/nilfs2/dir.c | 3 ++- > fs/nilfs2/file.c | 2 ++ > fs/ntfs3/dir.c | 3 +++ > fs/ntfs3/file.c | 3 +++ > fs/ocfs2/file.c | 5 +++++ > fs/orangefs/dir.c | 4 +++- > fs/orangefs/file.c | 1 + > fs/overlayfs/file.c | 2 ++ > fs/overlayfs/readdir.c | 2 ++ > fs/qnx4/dir.c | 2 ++ > fs/qnx6/dir.c | 2 ++ > fs/read_write.c | 2 ++ > fs/smb/client/cifsfs.c | 1 - > fs/squashfs/dir.c | 2 ++ > fs/squashfs/file.c | 4 +++- > fs/udf/dir.c | 2 ++ > fs/udf/file.c | 2 ++ > fs/ufs/dir.c | 2 ++ > fs/ufs/file.c | 2 ++ > fs/vboxsf/dir.c | 1 - > fs/vboxsf/file.c | 1 - > fs/xfs/xfs_file.c | 3 +++ > include/linux/fs.h | 1 - > mm/shmem.c | 2 ++ > 61 files changed, 116 insertions(+), 42 deletions(-) > --- > base-commit: 731ce71a6c8adb8b8f873643beacaeedc1564500 > change-id: 20260107-setlease-6-20-299eb5695c5a > > Best regards, > -- > Jeff Layton <jlayton@kernel.org> > -- Jan Kara <jack@suse.com> SUSE Labs, CR
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 delegation 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 lease support be more
> > opt-in, rather than opt-out:
> >
> > For historical reasons, when ->setlease() file_operation is set to NULL,
> > the default is to use the kernel-internal lease implementation. This
> > means that if you want to disable them, you need to explicitly set the
> > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> >
> > This has caused a number of problems over the years as some filesystems
> > have inadvertantly allowed leases to be acquired simply by having left
> > it set to NULL. It would be better if filesystems had to opt-in to lease
> > support, particularly with the advent of directory delegations.
> >
> > This series has sets the ->setlease() operation in a pile of existing
> > local filesystems to generic_setlease() and then changes
> > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > set.
> >
> > With this change, new filesystems will need to explicitly set the
> > ->setlease() operations in order to provide lease and delegation
> > support.
> >
> > I mainly focused on filesystems that are NFS exportable, since NFS and
> > SMB are the main users of file leases, and they tend to end up exporting
> > the same filesystem types. Let me know if I've missed any.
>
> So, what about kernfs and fuse? They seem to be exportable and don't have
> .setlease set...
>
Yes, FUSE needs this too. I'll add a patch for that.
As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
are built on. Do we really expect people to set leases there?
I guess it's technically a regression since you could set them on those
sorts of files earlier, but people don't usually export kernfs based
filesystems via NFS or SMB, and that seems like something that could be
used to make mischief.
AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
commit aa8188253474 ("kernfs: add exportfs operations").
One idea: we could add a wrapper around generic_setlease() for
filesystems like this that will do a WARN_ONCE() and then call
generic_setlease(). That would keep leases working on them but we might
get some reports that would tell us who's setting leases on these files
and why.
Thanks for the review!
> >
> > [1]: https://lore.kernel.org/linux-fsdevel/20260107-setlease-6-19-v1-0-85f034abcc57@kernel.org/
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Jeff Layton (24):
> > fs: add setlease to generic_ro_fops and read-only filesystem directory operations
> > affs: add setlease file operation
> > btrfs: add setlease file operation
> > erofs: add setlease file operation
> > ext2: add setlease file operation
> > ext4: add setlease file operation
> > exfat: add setlease file operation
> > f2fs: add setlease file operation
> > fat: add setlease file operation
> > gfs2: add a setlease file operation
> > jffs2: add setlease file operation
> > jfs: add setlease file operation
> > nilfs2: add setlease file operation
> > ntfs3: add setlease file operation
> > ocfs2: add setlease file operation
> > orangefs: add setlease file operation
> > overlayfs: add setlease file operation
> > squashfs: add setlease file operation
> > tmpfs: add setlease file operation
> > udf: add setlease file operation
> > ufs: add setlease file operation
> > xfs: add setlease file operation
> > filelock: default to returning -EINVAL when ->setlease operation is NULL
> > fs: remove simple_nosetlease()
> >
> > Documentation/filesystems/porting.rst | 9 +++++++++
> > Documentation/filesystems/vfs.rst | 9 ++++++---
> > fs/9p/vfs_dir.c | 2 --
> > fs/9p/vfs_file.c | 2 --
> > fs/affs/dir.c | 2 ++
> > fs/affs/file.c | 2 ++
> > fs/befs/linuxvfs.c | 2 ++
> > fs/btrfs/file.c | 2 ++
> > fs/btrfs/inode.c | 2 ++
> > fs/ceph/dir.c | 2 --
> > fs/ceph/file.c | 1 -
> > fs/cramfs/inode.c | 2 ++
> > fs/efs/dir.c | 2 ++
> > fs/erofs/data.c | 2 ++
> > fs/erofs/dir.c | 2 ++
> > fs/exfat/dir.c | 2 ++
> > fs/exfat/file.c | 2 ++
> > fs/ext2/dir.c | 2 ++
> > fs/ext2/file.c | 2 ++
> > fs/ext4/dir.c | 2 ++
> > fs/ext4/file.c | 2 ++
> > fs/f2fs/dir.c | 2 ++
> > fs/f2fs/file.c | 2 ++
> > fs/fat/dir.c | 2 ++
> > fs/fat/file.c | 2 ++
> > fs/freevxfs/vxfs_lookup.c | 2 ++
> > fs/fuse/dir.c | 1 -
> > fs/gfs2/file.c | 3 +--
> > fs/isofs/dir.c | 2 ++
> > fs/jffs2/dir.c | 2 ++
> > fs/jffs2/file.c | 2 ++
> > fs/jfs/file.c | 2 ++
> > fs/jfs/namei.c | 2 ++
> > fs/libfs.c | 20 ++------------------
> > fs/locks.c | 3 +--
> > fs/nfs/dir.c | 1 -
> > fs/nfs/file.c | 1 -
> > fs/nilfs2/dir.c | 3 ++-
> > fs/nilfs2/file.c | 2 ++
> > fs/ntfs3/dir.c | 3 +++
> > fs/ntfs3/file.c | 3 +++
> > fs/ocfs2/file.c | 5 +++++
> > fs/orangefs/dir.c | 4 +++-
> > fs/orangefs/file.c | 1 +
> > fs/overlayfs/file.c | 2 ++
> > fs/overlayfs/readdir.c | 2 ++
> > fs/qnx4/dir.c | 2 ++
> > fs/qnx6/dir.c | 2 ++
> > fs/read_write.c | 2 ++
> > fs/smb/client/cifsfs.c | 1 -
> > fs/squashfs/dir.c | 2 ++
> > fs/squashfs/file.c | 4 +++-
> > fs/udf/dir.c | 2 ++
> > fs/udf/file.c | 2 ++
> > fs/ufs/dir.c | 2 ++
> > fs/ufs/file.c | 2 ++
> > fs/vboxsf/dir.c | 1 -
> > fs/vboxsf/file.c | 1 -
> > fs/xfs/xfs_file.c | 3 +++
> > include/linux/fs.h | 1 -
> > mm/shmem.c | 2 ++
> > 61 files changed, 116 insertions(+), 42 deletions(-)
> > ---
> > base-commit: 731ce71a6c8adb8b8f873643beacaeedc1564500
> > change-id: 20260107-setlease-6-20-299eb5695c5a
> >
> > Best regards,
> > --
> > Jeff Layton <jlayton@kernel.org>
> >
--
Jeff Layton <jlayton@kernel.org>
On Thu, Jan 8, 2026 at 7:57 PM Jeff Layton <jlayton@kernel.org> wrote:
>
> 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 delegation 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 lease support be more
> > > opt-in, rather than opt-out:
> > >
> > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > the default is to use the kernel-internal lease implementation. This
> > > means that if you want to disable them, you need to explicitly set the
> > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > >
> > > This has caused a number of problems over the years as some filesystems
> > > have inadvertantly allowed leases to be acquired simply by having left
> > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > support, particularly with the advent of directory delegations.
> > >
> > > This series has sets the ->setlease() operation in a pile of existing
> > > local filesystems to generic_setlease() and then changes
> > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > set.
> > >
> > > With this change, new filesystems will need to explicitly set the
> > > ->setlease() operations in order to provide lease and delegation
> > > support.
> > >
> > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > SMB are the main users of file leases, and they tend to end up exporting
> > > the same filesystem types. Let me know if I've missed any.
> >
> > So, what about kernfs and fuse? They seem to be exportable and don't have
> > .setlease set...
> >
>
> Yes, FUSE needs this too. I'll add a patch for that.
>
> As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> are built on. Do we really expect people to set leases there?
>
> I guess it's technically a regression since you could set them on those
> sorts of files earlier, but people don't usually export kernfs based
> filesystems via NFS or SMB, and that seems like something that could be
> used to make mischief.
>
> AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> commit aa8188253474 ("kernfs: add exportfs operations").
>
> One idea: we could add a wrapper around generic_setlease() for
> filesystems like this that will do a WARN_ONCE() and then call
> generic_setlease(). That would keep leases working on them but we might
> get some reports that would tell us who's setting leases on these files
> and why.
IMO, you are being too cautious, but whatever.
It is not accurate that kernfs filesystems are NFS exportable in general.
Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
If any application is using leases on cgroup files, it must be some
very advanced runtime (i.e. systemd), so we should know about the
regression sooner rather than later.
There are also the recently added nsfs and pidfs export_operations.
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.
Christian? Do you remember?
Thanks,
Amir.
On Fri, 2026-01-09 at 19:52 +0100, Amir Goldstein wrote:
> On Thu, Jan 8, 2026 at 7:57 PM Jeff Layton <jlayton@kernel.org> wrote:
> >
> > 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 delegation 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 lease support be more
> > > > opt-in, rather than opt-out:
> > > >
> > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > the default is to use the kernel-internal lease implementation. This
> > > > means that if you want to disable them, you need to explicitly set the
> > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > >
> > > > This has caused a number of problems over the years as some filesystems
> > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > support, particularly with the advent of directory delegations.
> > > >
> > > > This series has sets the ->setlease() operation in a pile of existing
> > > > local filesystems to generic_setlease() and then changes
> > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > set.
> > > >
> > > > With this change, new filesystems will need to explicitly set the
> > > > ->setlease() operations in order to provide lease and delegation
> > > > support.
> > > >
> > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > the same filesystem types. Let me know if I've missed any.
> > >
> > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > .setlease set...
> > >
> >
> > Yes, FUSE needs this too. I'll add a patch for that.
> >
> > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > are built on. Do we really expect people to set leases there?
> >
> > I guess it's technically a regression since you could set them on those
> > sorts of files earlier, but people don't usually export kernfs based
> > filesystems via NFS or SMB, and that seems like something that could be
> > used to make mischief.
> >
> > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > commit aa8188253474 ("kernfs: add exportfs operations").
> >
> > One idea: we could add a wrapper around generic_setlease() for
> > filesystems like this that will do a WARN_ONCE() and then call
> > generic_setlease(). That would keep leases working on them but we might
> > get some reports that would tell us who's setting leases on these files
> > and why.
>
> IMO, you are being too cautious, but whatever.
>
> It is not accurate that kernfs filesystems are NFS exportable in general.
> Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
>
> If any application is using leases on cgroup files, it must be some
> very advanced runtime (i.e. systemd), so we should know about the
> regression sooner rather than later.
>
I think so too. For now, I think I'll not bother with the WARN_ONCE().
Let's just leave kernfs out of the set until someone presents a real
use-case.
> There are also the recently added nsfs and pidfs export_operations.
>
> 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.
>
> Christian? Do you remember?
>
(cc'ing Chuck)
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 NFSv4, 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.
Should we add a mechanism to prevent exporting these sorts of
filesystems?
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_verify()? We'd
have to add it to a bunch of existing filesystems, but that's fairly
simple to do with an LLM.
--
Jeff Layton <jlayton@kernel.org>
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 PM Jeff Layton <jlayton@kernel.org> wrote:
>>>
>>> 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 delegation 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 lease support be more
>>>>> opt-in, rather than opt-out:
>>>>>
>>>>> For historical reasons, when ->setlease() file_operation is set to NULL,
>>>>> the default is to use the kernel-internal lease implementation. This
>>>>> means that if you want to disable them, you need to explicitly set the
>>>>> ->setlease() file_operation to simple_nosetlease() or the equivalent.
>>>>>
>>>>> This has caused a number of problems over the years as some filesystems
>>>>> have inadvertantly allowed leases to be acquired simply by having left
>>>>> it set to NULL. It would be better if filesystems had to opt-in to lease
>>>>> support, particularly with the advent of directory delegations.
>>>>>
>>>>> This series has sets the ->setlease() operation in a pile of existing
>>>>> local filesystems to generic_setlease() and then changes
>>>>> kernel_setlease() to return -EINVAL when the setlease() operation is not
>>>>> set.
>>>>>
>>>>> With this change, new filesystems will need to explicitly set the
>>>>> ->setlease() operations in order to provide lease and delegation
>>>>> support.
>>>>>
>>>>> I mainly focused on filesystems that are NFS exportable, since NFS and
>>>>> SMB are the main users of file leases, and they tend to end up exporting
>>>>> the same filesystem types. Let me know if I've missed any.
>>>>
>>>> So, what about kernfs and fuse? They seem to be exportable and don't have
>>>> .setlease set...
>>>>
>>>
>>> Yes, FUSE needs this too. I'll add a patch for that.
>>>
>>> As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
>>> are built on. Do we really expect people to set leases there?
>>>
>>> I guess it's technically a regression since you could set them on those
>>> sorts of files earlier, but people don't usually export kernfs based
>>> filesystems via NFS or SMB, and that seems like something that could be
>>> used to make mischief.
>>>
>>> AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
>>> commit aa8188253474 ("kernfs: add exportfs operations").
>>>
>>> One idea: we could add a wrapper around generic_setlease() for
>>> filesystems like this that will do a WARN_ONCE() and then call
>>> generic_setlease(). That would keep leases working on them but we might
>>> get some reports that would tell us who's setting leases on these files
>>> and why.
>>
>> IMO, you are being too cautious, but whatever.
>>
>> It is not accurate that kernfs filesystems are NFS exportable in general.
>> Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
>>
>> If any application is using leases on cgroup files, it must be some
>> very advanced runtime (i.e. systemd), so we should know about the
>> regression sooner rather than later.
>>
>
> I think so too. For now, I think I'll not bother with the WARN_ONCE().
> Let's just leave kernfs out of the set until someone presents a real
> use-case.
>
>> There are also the recently added nsfs and pidfs export_operations.
>>
>> 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.
>>
>> Christian? Do you remember?
>>
>
> (cc'ing Chuck)
>
> 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 NFSv4, 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.
>
> Should we add a mechanism to prevent exporting these sorts of
> filesystems?
>
> 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_verify()? We'd
> have to add it to a bunch of existing filesystems, but that's fairly
> simple to do with an LLM.
What's the active harm in exporting /sys/fs/cgroup ? It has to be done
explicitly via /etc/exports, so this is under the NFS server admin's
control. Is it an attack surface?
--
Chuck Lever
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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > >
> > > > 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 delegation 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 lease support be more
> > > > > > opt-in, rather than opt-out:
> > > > > >
> > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > >
> > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > support, particularly with the advent of directory delegations.
> > > > > >
> > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > local filesystems to generic_setlease() and then changes
> > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > set.
> > > > > >
> > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > support.
> > > > > >
> > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > the same filesystem types. Let me know if I've missed any.
> > > > >
> > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > .setlease set...
> > > > >
> > > >
> > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > >
> > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > are built on. Do we really expect people to set leases there?
> > > >
> > > > I guess it's technically a regression since you could set them on those
> > > > sorts of files earlier, but people don't usually export kernfs based
> > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > used to make mischief.
> > > >
> > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > >
> > > > One idea: we could add a wrapper around generic_setlease() for
> > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > generic_setlease(). That would keep leases working on them but we might
> > > > get some reports that would tell us who's setting leases on these files
> > > > and why.
> > >
> > > IMO, you are being too cautious, but whatever.
> > >
> > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > >
> > > If any application is using leases on cgroup files, it must be some
> > > very advanced runtime (i.e. systemd), so we should know about the
> > > regression sooner rather than later.
> > >
> >
> > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > Let's just leave kernfs out of the set until someone presents a real
> > use-case.
> >
> > > There are also the recently added nsfs and pidfs export_operations.
> > >
> > > 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.
> > >
> > > Christian? Do you remember?
> > >
> >
> > (cc'ing Chuck)
> >
> > 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 NFSv4, 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.
> >
> > Should we add a mechanism to prevent exporting these sorts of
> > filesystems?
> >
> > 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_verify()? We'd
> > have to add it to a bunch of existing filesystems, but that's fairly
> > simple to do with an LLM.
>
> What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> explicitly via /etc/exports, so this is under the NFS server admin's
> control. Is it an attack surface?
>
Potentially?
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.
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.
Having an explicit "I want to allow nfsd" flag see ms like it might
save us some headaches in the future when other filesystems add export
ops for this sort of filehandle use.
--
Jeff Layton <jlayton@kernel.org>
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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > >
> > > > > 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 delegation 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 lease support be more
> > > > > > > opt-in, rather than opt-out:
> > > > > > >
> > > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > > >
> > > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > > support, particularly with the advent of directory delegations.
> > > > > > >
> > > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > > local filesystems to generic_setlease() and then changes
> > > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > > set.
> > > > > > >
> > > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > > support.
> > > > > > >
> > > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > > the same filesystem types. Let me know if I've missed any.
> > > > > >
> > > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > > .setlease set...
> > > > > >
> > > > >
> > > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > > >
> > > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > > are built on. Do we really expect people to set leases there?
> > > > >
> > > > > I guess it's technically a regression since you could set them on those
> > > > > sorts of files earlier, but people don't usually export kernfs based
> > > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > > used to make mischief.
> > > > >
> > > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > > >
> > > > > One idea: we could add a wrapper around generic_setlease() for
> > > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > > generic_setlease(). That would keep leases working on them but we might
> > > > > get some reports that would tell us who's setting leases on these files
> > > > > and why.
> > > >
> > > > IMO, you are being too cautious, but whatever.
> > > >
> > > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > > >
> > > > If any application is using leases on cgroup files, it must be some
> > > > very advanced runtime (i.e. systemd), so we should know about the
> > > > regression sooner rather than later.
> > > >
> > >
> > > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > > Let's just leave kernfs out of the set until someone presents a real
> > > use-case.
> > >
> > > > There are also the recently added nsfs and pidfs export_operations.
> > > >
> > > > 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.
> > > >
> > > > Christian? Do you remember?
> > > >
> > >
> > > (cc'ing Chuck)
> > >
> > > 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 NFSv4, 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.
> > >
> > > Should we add a mechanism to prevent exporting these sorts of
> > > filesystems?
> > >
> > > 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_verify()? We'd
> > > have to add it to a bunch of existing filesystems, but that's fairly
> > > simple to do with an LLM.
> >
> > What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> > explicitly via /etc/exports, so this is under the NFS server admin's
> > control. Is it an attack surface?
> >
>
> Potentially?
>
> 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.
>
> 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.
>
> Having an explicit "I want to allow nfsd" flag see ms like it might
> save us some headaches in the future when other filesystems add export
> ops for this sort of filehandle use.
So we are re-hashing a discussion we had a few months ago (Amir was
involved at least).
I don't think we want to expose cgroupfs via NFS that's super weird.
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.
So my preference would be to really sever file handles from the export
mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
use file handles via name_to_handle_at() and open_by_handle_at() without
making them exportable.
Somehow I thought that Amir had already done that work a while ago but
maybe it was really just about name_to_handle_at() and not also
open_by_handle_at()...
On Tue, Jan 13, 2026 at 09:54:15AM +0100, Christian Brauner wrote: > I don't think we want to expose cgroupfs via NFS that's super weird. > 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. > > So my preference would be to really sever file handles from the export > mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to > use file handles via name_to_handle_at() and open_by_handle_at() without > making them exportable. I don't understand this discussion. If someone really wants to expose say cgroupfs to the network they'll find a way, be that using a userspace nfs server, samba, 9p or a custom fuse thing. What's the benefit of explicitly prohibiting a knfsd export? (not that I think any of this makes much sense to start with)
On Tue, 2026-01-13 at 06:54 -0800, Christoph Hellwig wrote: > On Tue, Jan 13, 2026 at 09:54:15AM +0100, Christian Brauner wrote: > > I don't think we want to expose cgroupfs via NFS that's super weird. > > 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. > > > > So my preference would be to really sever file handles from the export > > mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to > > use file handles via name_to_handle_at() and open_by_handle_at() without > > making them exportable. > > I don't understand this discussion. If someone really wants to > expose say cgroupfs to the network they'll find a way, be that using > a userspace nfs server, samba, 9p or a custom fuse thing. What's the > benefit of explicitly prohibiting a knfsd export? > > (not that I think any of this makes much sense to start with) Fair point, but it's not that hard to conceive of a situation where someone inadvertantly exports cgroupfs or some similar filesystem: Could you end up exporting /sys if it's bind mounted into a container somewhere? Bear in mind that exportfs does allow mountpoint crossing, etc. nfsd is a network service, so I think the kernel needs to be quite conservative about what filehandles it can access. -- Jeff Layton <jlayton@kernel.org>
On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > Fair point, but it's not that hard to conceive of a situation where > someone inadvertantly exports cgroupfs or some similar filesystem: Sure. But how is this worse than accidentally exporting private data or any other misconfiguration?
On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > Fair point, but it's not that hard to conceive of a situation where > > someone inadvertantly exports cgroupfs or some similar filesystem: > > Sure. But how is this worse than accidentally exporting private data > or any other misconfiguration? > My POV is that it is less about security (as your question implies), and more about correctness. The special thing about NFS export, as opposed to, say, ksmbd, is open by file handle, IOW, the export_operations. I perceive this as a very strange and undesired situation when NFS file handles do not behave as persistent file handles. FUSE will gladly open a completely different object, sometimes a different object type from an NFS client request after server restart. I suppose that the same could happen with tmpfs and probably some other fs. This problem is old and welded into the system, but IMO adding more kernel filesystems, which consciously export file handles that do not survive server reboot does not serve users interests well. One could claim that this is a bug that can be fixed by adding boot_id to said file handles, but why fix something that nobody asked for? cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for a known reason, which was NOT NFS export. If the author of open_by_handle_at() support (i.e. brauner) does not wish to imply that those fs should be exported to NFS, why object? We could have the opt-in/out of NFS export fixes per EXPORT_OP_ flags and we could even think of allowing admin to make this decision per vfsmount (e.g. for cgroupfs). In any case, I fail to see how objecting to the possibility of NFS export opt-out serves anyone. Thanks, Amir.
On Wed, 14 Jan 2026 10:34:04 +0100 Amir Goldstein <amir73il@gmail.com> wrote: > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > Fair point, but it's not that hard to conceive of a situation where > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > Sure. But how is this worse than accidentally exporting private data > > or any other misconfiguration? > > > > My POV is that it is less about security (as your question implies), and > more about correctness. > > The special thing about NFS export, as opposed to, say, ksmbd, is > open by file handle, IOW, the export_operations. > > I perceive this as a very strange and undesired situation when NFS > file handles do not behave as persistent file handles. > > FUSE will gladly open a completely different object, sometimes > a different object type from an NFS client request after server restart. > > I suppose that the same could happen with tmpfs and probably some > other fs. ... You really shouldn't be allowed to nfs export a fs that doesn't have persistent file handles. Even file handles containing 'random' numbers can be problematic. The default used to be 'hard mounts' (not sure it is any more) which caused the client (not Linux - too long ago) to loop in kernel forever waiting for the server to recover the filesystem export. The only resolution on that system was to reboot the client. At least nfs can now use variable size file-ids. When I was fixing some code that exported a layered fs (I pretty much rewrote the fs at the same time) I did randomise the file-ids so they (hopefully) became invalid after a reboot (only after suffering some very corrupt filesystems!) I found nfs (over udp) had some interesting 'features': - If you export part of a fs you export all of it. (Especially since this predated the randomisation of the inode generation number.) - If you give anyone access you give everyone access. - If you give anyone write access you give everyone write access. The latter two because the 'mount' protocol wasn't really needed and the server didn't care where requests came from. David
On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > Fair point, but it's not that hard to conceive of a situation where > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > Sure. But how is this worse than accidentally exporting private data > > or any other misconfiguration? > > > > My POV is that it is less about security (as your question implies), and > more about correctness. I was just replying to Jeff. > The special thing about NFS export, as opposed to, say, ksmbd, is > open by file handle, IOW, the export_operations. > > I perceive this as a very strange and undesired situation when NFS > file handles do not behave as persistent file handles. That is not just very strange, but actually broken (discounting the obscure volatile file handles features not implemented in Linux NFS and NFSD). And the export ops always worked under the assumption that these file handles are indeed persistent. If they're not we do have a problem. > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > a known reason, which was NOT NFS export. > > If the author of open_by_handle_at() support (i.e. brauner) does not > wish to imply that those fs should be exported to NFS, why object? Because "want to export" is a stupid category. OTOH "NFS exporting doesn't actually properly work because someone overloaded export_ops with different semantics" is a valid category. > We could have the opt-in/out of NFS export fixes per EXPORT_OP_ > flags and we could even think of allowing admin to make this decision > per vfsmount (e.g. for cgroupfs). > > In any case, I fail to see how objecting to the possibility of NFS export > opt-out serves anyone. 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.
On Wed, Jan 14, 2026 at 05:06:07AM -0800, Christoph Hellwig wrote: > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > Fair point, but it's not that hard to conceive of a situation where > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > Sure. But how is this worse than accidentally exporting private data > > > or any other misconfiguration? > > > > > > > My POV is that it is less about security (as your question implies), and > > more about correctness. > > I was just replying to Jeff. > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > open by file handle, IOW, the export_operations. > > > > I perceive this as a very strange and undesired situation when NFS > > file handles do not behave as persistent file handles. > > That is not just very strange, but actually broken (discounting the > obscure volatile file handles features not implemented in Linux NFS > and NFSD). And the export ops always worked under the assumption > that these file handles are indeed persistent. If they're not we > do have a problem. > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > a known reason, which was NOT NFS export. > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > wish to imply that those fs should be exported to NFS, why object? > > Because "want to export" is a stupid category. > > OTOH "NFS exporting doesn't actually properly work because someone > overloaded export_ops with different semantics" is a valid category. > > > We could have the opt-in/out of NFS export fixes per EXPORT_OP_ > > flags and we could even think of allowing admin to make this decision > > per vfsmount (e.g. for cgroupfs). > > > > In any case, I fail to see how objecting to the possibility of NFS export > > opt-out serves anyone. > > 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. How that is achieved is completely irrelevant to that core part of the argument. The point Jeff and Amir are making that it is sensible to allow one without the other. Whether or not some userspace crap allows you to achieve the same thing is entirely irrelevant and does not at all imply we have to allow the same crap in the kernel.
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.
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.
On Thu, Jan 15, 2026 at 09:14:06AM +0100, Christian Brauner wrote: > 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. I can't even parse what you mean. And no, I hate these stupid arguments, and I have much better things to do than dragging this on. > > 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. None of that is a technical argument. The lack of stable file handles would be one, and I think we came to the conclusion yesterday that this is the case.
On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote: > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > Fair point, but it's not that hard to conceive of a situation where > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > Sure. But how is this worse than accidentally exporting private data > > > or any other misconfiguration? > > > > > > > My POV is that it is less about security (as your question implies), and > > more about correctness. > > I was just replying to Jeff. > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > open by file handle, IOW, the export_operations. > > > > I perceive this as a very strange and undesired situation when NFS > > file handles do not behave as persistent file handles. > > That is not just very strange, but actually broken (discounting the > obscure volatile file handles features not implemented in Linux NFS > and NFSD). And the export ops always worked under the assumption > that these file handles are indeed persistent. If they're not we > do have a problem. > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > a known reason, which was NOT NFS export. > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > wish to imply that those fs should be exported to NFS, why object? > > Because "want to export" is a stupid category. > > OTOH "NFS exporting doesn't actually properly work because someone > overloaded export_ops with different semantics" is a valid category. > cgroupfs definitely doesn't behave as expected when exported via NFS. The files aren't readable, at least. I'd also be surprised if the filehandles were stable across a reboot, which is sort of necessary for proper operation. I didn't test writing, but who knows whether that might also just not work, crash the box, or do something else entirely. I imagine this is the case for all sorts of filesystems like /proc, /sys, etc. Those aren't exportable today (to my knowledge), but we're growing export_operations across a wide range of fs's these days. I'd prefer that we require someone to take the deliberate step to say "yes, allow nfsd to access this type of filesystem". > > We could have the opt-in/out of NFS export fixes per EXPORT_OP_ > > flags and we could even think of allowing admin to make this decision > > per vfsmount (e.g. for cgroupfs). > > > > In any case, I fail to see how objecting to the possibility of NFS export > > opt-out serves anyone. > > 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. The problem there is that we very much do want to keep tmpfs exportable, but it doesn't have stable handles (per-se). -- Jeff Layton <jlayton@kernel.org>
On Wed, Jan 14, 2026 at 08:41:16AM -0500, Jeff Layton wrote: > On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote: > > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > > Fair point, but it's not that hard to conceive of a situation where > > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > > > Sure. But how is this worse than accidentally exporting private data > > > > or any other misconfiguration? > > > > > > > > > > My POV is that it is less about security (as your question implies), and > > > more about correctness. > > > > I was just replying to Jeff. > > > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > > open by file handle, IOW, the export_operations. > > > > > > I perceive this as a very strange and undesired situation when NFS > > > file handles do not behave as persistent file handles. > > > > That is not just very strange, but actually broken (discounting the > > obscure volatile file handles features not implemented in Linux NFS > > and NFSD). And the export ops always worked under the assumption > > that these file handles are indeed persistent. If they're not we > > do have a problem. > > > > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > > a known reason, which was NOT NFS export. > > > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > > wish to imply that those fs should be exported to NFS, why object? > > > > Because "want to export" is a stupid category. > > > > OTOH "NFS exporting doesn't actually properly work because someone > > overloaded export_ops with different semantics" is a valid category. > > > > cgroupfs definitely doesn't behave as expected when exported via NFS. > The files aren't readable, at least. I'd also be surprised if the > filehandles were stable across a reboot, which is sort of necessary for They aren't and it's not desirable.
On Wed, Jan 14, 2026 at 2:41 PM Jeff Layton <jlayton@kernel.org> wrote: > > On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote: > > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote: > > > > > Fair point, but it's not that hard to conceive of a situation where > > > > > someone inadvertantly exports cgroupfs or some similar filesystem: > > > > > > > > Sure. But how is this worse than accidentally exporting private data > > > > or any other misconfiguration? > > > > > > > > > > My POV is that it is less about security (as your question implies), and > > > more about correctness. > > > > I was just replying to Jeff. > > > > > The special thing about NFS export, as opposed to, say, ksmbd, is > > > open by file handle, IOW, the export_operations. > > > > > > I perceive this as a very strange and undesired situation when NFS > > > file handles do not behave as persistent file handles. > > > > That is not just very strange, but actually broken (discounting the > > obscure volatile file handles features not implemented in Linux NFS > > and NFSD). And the export ops always worked under the assumption > > that these file handles are indeed persistent. If they're not we > > do have a problem. > > > > > > > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for > > > a known reason, which was NOT NFS export. > > > > > > If the author of open_by_handle_at() support (i.e. brauner) does not > > > wish to imply that those fs should be exported to NFS, why object? > > > > Because "want to export" is a stupid category. > > > > OTOH "NFS exporting doesn't actually properly work because someone > > overloaded export_ops with different semantics" is a valid category. > > > > cgroupfs definitely doesn't behave as expected when exported via NFS. > The files aren't readable, at least. I'd also be surprised if the > filehandles were stable across a reboot, which is sort of necessary for > proper operation. I didn't test writing, but who knows whether that > might also just not work, crash the box, or do something else entirely. > > I imagine this is the case for all sorts of filesystems like /proc, > /sys, etc. Those aren't exportable today (to my knowledge), but we're > growing export_operations across a wide range of fs's these days. > > I'd prefer that we require someone to take the deliberate step to say > "yes, allow nfsd to access this type of filesystem". > > > > We could have the opt-in/out of NFS export fixes per EXPORT_OP_ > > > flags and we could even think of allowing admin to make this decision > > > per vfsmount (e.g. for cgroupfs). > > > > > > In any case, I fail to see how objecting to the possibility of NFS export > > > opt-out serves anyone. > > > > 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. > Very well then. How about EXPORT_OP_PERSISTENT_HANDLES? This terminology is from the NFS protocol spec and it is also used to describe the same trait in SMB protocol. > The problem there is that we very much do want to keep tmpfs > exportable, but it doesn't have stable handles (per-se). Thinking out loud - It would be misguided to declare tmpfs as EXPORT_OP_PERSISTENT_HANDLES and regressing exports of tmpfs will surely not go unnoticed. How about adding an exportfs option "persistent_handles", use it as default IFF neither options fsid=, uuid= are used, so that at least when exporting tmpfs, exportfs -v will show "no_persistent_handles" explicitly? Thanks, Amir.
On Wed, Jan 14, 2026 at 03:14:13PM +0100, Amir Goldstein wrote: > Very well then. > How about EXPORT_OP_PERSISTENT_HANDLES? Sure. > > The problem there is that we very much do want to keep tmpfs > > exportable, but it doesn't have stable handles (per-se). > > Thinking out loud - > It would be misguided to declare tmpfs as > EXPORT_OP_PERSISTENT_HANDLES > and regressing exports of tmpfs will surely not go unnoticed. tmpfs handles are stable. It's the tmpfs files that don't survive an unmount or reboot..
On Wed, Jan 14, 2026 at 07:05:19AM -0800, Christoph Hellwig wrote: > On Wed, Jan 14, 2026 at 03:14:13PM +0100, Amir Goldstein wrote: > > Very well then. > > How about EXPORT_OP_PERSISTENT_HANDLES? > > Sure. That sounds good to me too.
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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > > >
> > > > > > 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 delegation 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 lease support be more
> > > > > > > > opt-in, rather than opt-out:
> > > > > > > >
> > > > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > > > >
> > > > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > > > support, particularly with the advent of directory delegations.
> > > > > > > >
> > > > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > > > local filesystems to generic_setlease() and then changes
> > > > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > > > set.
> > > > > > > >
> > > > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > > > support.
> > > > > > > >
> > > > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > > > the same filesystem types. Let me know if I've missed any.
> > > > > > >
> > > > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > > > .setlease set...
> > > > > > >
> > > > > >
> > > > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > > > >
> > > > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > > > are built on. Do we really expect people to set leases there?
> > > > > >
> > > > > > I guess it's technically a regression since you could set them on those
> > > > > > sorts of files earlier, but people don't usually export kernfs based
> > > > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > > > used to make mischief.
> > > > > >
> > > > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > > > >
> > > > > > One idea: we could add a wrapper around generic_setlease() for
> > > > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > > > generic_setlease(). That would keep leases working on them but we might
> > > > > > get some reports that would tell us who's setting leases on these files
> > > > > > and why.
> > > > >
> > > > > IMO, you are being too cautious, but whatever.
> > > > >
> > > > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > > > >
> > > > > If any application is using leases on cgroup files, it must be some
> > > > > very advanced runtime (i.e. systemd), so we should know about the
> > > > > regression sooner rather than later.
> > > > >
> > > >
> > > > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > > > Let's just leave kernfs out of the set until someone presents a real
> > > > use-case.
> > > >
> > > > > There are also the recently added nsfs and pidfs export_operations.
> > > > >
> > > > > 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.
> > > > >
> > > > > Christian? Do you remember?
> > > > >
> > > >
> > > > (cc'ing Chuck)
> > > >
> > > > 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 NFSv4, 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.
> > > >
> > > > Should we add a mechanism to prevent exporting these sorts of
> > > > filesystems?
> > > >
> > > > 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_verify()? We'd
> > > > have to add it to a bunch of existing filesystems, but that's fairly
> > > > simple to do with an LLM.
> > >
> > > What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> > > explicitly via /etc/exports, so this is under the NFS server admin's
> > > control. Is it an attack surface?
> > >
> >
> > Potentially?
> >
> > 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.
> >
> > 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.
> >
> > Having an explicit "I want to allow nfsd" flag see ms like it might
> > save us some headaches in the future when other filesystems add export
> > ops for this sort of filehandle use.
>
> So we are re-hashing a discussion we had a few months ago (Amir was
> involved at least).
>
Yep, I was lurking on it, but didn't have a lot of input at the time.
> I don't think we want to expose cgroupfs via NFS that's super weird.
> 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.
>
> So my preference would be to really sever file handles from the export
> mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
> use file handles via name_to_handle_at() and open_by_handle_at() without
> making them exportable.
Agreed. I think we want to make NFS export be a deliberate opt-in
decision that filesystem developers make. How we do that is up for
debate, of course.
An export ops flag would be fairly simple to implement, but it sounds
like you're thinking that we should split some export_operations into
struct file_handle_operations and then add a pointer for that to
super_block (and maybe to export_operations too)?
This would be a good LSF/MM topic, but I'm hoping we can come to a
consensus before then.
--
Jeff Layton <jlayton@kernel.org>
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 PM Jeff Layton <jlayton@kernel.org> wrote:
>>>>>>>
>>>>>>> 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 delegation 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 lease support be more
>>>>>>>>> opt-in, rather than opt-out:
>>>>>>>>>
>>>>>>>>> For historical reasons, when ->setlease() file_operation is set to NULL,
>>>>>>>>> the default is to use the kernel-internal lease implementation. This
>>>>>>>>> means that if you want to disable them, you need to explicitly set the
>>>>>>>>> ->setlease() file_operation to simple_nosetlease() or the equivalent.
>>>>>>>>>
>>>>>>>>> This has caused a number of problems over the years as some filesystems
>>>>>>>>> have inadvertantly allowed leases to be acquired simply by having left
>>>>>>>>> it set to NULL. It would be better if filesystems had to opt-in to lease
>>>>>>>>> support, particularly with the advent of directory delegations.
>>>>>>>>>
>>>>>>>>> This series has sets the ->setlease() operation in a pile of existing
>>>>>>>>> local filesystems to generic_setlease() and then changes
>>>>>>>>> kernel_setlease() to return -EINVAL when the setlease() operation is not
>>>>>>>>> set.
>>>>>>>>>
>>>>>>>>> With this change, new filesystems will need to explicitly set the
>>>>>>>>> ->setlease() operations in order to provide lease and delegation
>>>>>>>>> support.
>>>>>>>>>
>>>>>>>>> I mainly focused on filesystems that are NFS exportable, since NFS and
>>>>>>>>> SMB are the main users of file leases, and they tend to end up exporting
>>>>>>>>> the same filesystem types. Let me know if I've missed any.
>>>>>>>>
>>>>>>>> So, what about kernfs and fuse? They seem to be exportable and don't have
>>>>>>>> .setlease set...
>>>>>>>>
>>>>>>>
>>>>>>> Yes, FUSE needs this too. I'll add a patch for that.
>>>>>>>
>>>>>>> As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
>>>>>>> are built on. Do we really expect people to set leases there?
>>>>>>>
>>>>>>> I guess it's technically a regression since you could set them on those
>>>>>>> sorts of files earlier, but people don't usually export kernfs based
>>>>>>> filesystems via NFS or SMB, and that seems like something that could be
>>>>>>> used to make mischief.
>>>>>>>
>>>>>>> AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
>>>>>>> commit aa8188253474 ("kernfs: add exportfs operations").
>>>>>>>
>>>>>>> One idea: we could add a wrapper around generic_setlease() for
>>>>>>> filesystems like this that will do a WARN_ONCE() and then call
>>>>>>> generic_setlease(). That would keep leases working on them but we might
>>>>>>> get some reports that would tell us who's setting leases on these files
>>>>>>> and why.
>>>>>>
>>>>>> IMO, you are being too cautious, but whatever.
>>>>>>
>>>>>> It is not accurate that kernfs filesystems are NFS exportable in general.
>>>>>> Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
>>>>>>
>>>>>> If any application is using leases on cgroup files, it must be some
>>>>>> very advanced runtime (i.e. systemd), so we should know about the
>>>>>> regression sooner rather than later.
>>>>>>
>>>>>
>>>>> I think so too. For now, I think I'll not bother with the WARN_ONCE().
>>>>> Let's just leave kernfs out of the set until someone presents a real
>>>>> use-case.
>>>>>
>>>>>> There are also the recently added nsfs and pidfs export_operations.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Christian? Do you remember?
>>>>>>
>>>>>
>>>>> (cc'ing Chuck)
>>>>>
>>>>> 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 NFSv4, 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.
>>>>>
>>>>> Should we add a mechanism to prevent exporting these sorts of
>>>>> filesystems?
>>>>>
>>>>> 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_verify()? We'd
>>>>> have to add it to a bunch of existing filesystems, but that's fairly
>>>>> simple to do with an LLM.
>>>>
>>>> What's the active harm in exporting /sys/fs/cgroup ? It has to be done
>>>> explicitly via /etc/exports, so this is under the NFS server admin's
>>>> control. Is it an attack surface?
>>>>
>>>
>>> Potentially?
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> Having an explicit "I want to allow nfsd" flag see ms like it might
>>> save us some headaches in the future when other filesystems add export
>>> ops for this sort of filehandle use.
>>
>> So we are re-hashing a discussion we had a few months ago (Amir was
>> involved at least).
>>
>
> Yep, I was lurking on it, but didn't have a lot of input at the time.
>
>> I don't think we want to expose cgroupfs via NFS that's super weird.
>> 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.
>>
>> So my preference would be to really sever file handles from the export
>> mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
>> use file handles via name_to_handle_at() and open_by_handle_at() without
>> making them exportable.
>
> Agreed. I think we want to make NFS export be a deliberate opt-in
> decision that filesystem developers make.
No objection, what about ksmbd, AFS, or Ceph?
> How we do that is up for
> debate, of course.
>
> An export ops flag would be fairly simple to implement, but it sounds
> like you're thinking that we should split some export_operations into
> struct file_handle_operations and then add a pointer for that to
> super_block (and maybe to export_operations too)?
>
> This would be a good LSF/MM topic, but I'm hoping we can come to a
> consensus before then.
>
--
Chuck Lever
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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > > > > >
> > > > > > > > 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 delegation 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 lease support be more
> > > > > > > > > > opt-in, rather than opt-out:
> > > > > > > > > >
> > > > > > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > > > > > >
> > > > > > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > > > > > support, particularly with the advent of directory delegations.
> > > > > > > > > >
> > > > > > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > > > > > local filesystems to generic_setlease() and then changes
> > > > > > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > > > > > set.
> > > > > > > > > >
> > > > > > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > > > > > support.
> > > > > > > > > >
> > > > > > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > > > > > the same filesystem types. Let me know if I've missed any.
> > > > > > > > >
> > > > > > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > > > > > .setlease set...
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > > > > > >
> > > > > > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > > > > > are built on. Do we really expect people to set leases there?
> > > > > > > >
> > > > > > > > I guess it's technically a regression since you could set them on those
> > > > > > > > sorts of files earlier, but people don't usually export kernfs based
> > > > > > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > > > > > used to make mischief.
> > > > > > > >
> > > > > > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > > > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > > > > > >
> > > > > > > > One idea: we could add a wrapper around generic_setlease() for
> > > > > > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > > > > > generic_setlease(). That would keep leases working on them but we might
> > > > > > > > get some reports that would tell us who's setting leases on these files
> > > > > > > > and why.
> > > > > > >
> > > > > > > IMO, you are being too cautious, but whatever.
> > > > > > >
> > > > > > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > > > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > > > > > >
> > > > > > > If any application is using leases on cgroup files, it must be some
> > > > > > > very advanced runtime (i.e. systemd), so we should know about the
> > > > > > > regression sooner rather than later.
> > > > > > >
> > > > > >
> > > > > > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > > > > > Let's just leave kernfs out of the set until someone presents a real
> > > > > > use-case.
> > > > > >
> > > > > > > There are also the recently added nsfs and pidfs export_operations.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Christian? Do you remember?
> > > > > > >
> > > > > >
> > > > > > (cc'ing Chuck)
> > > > > >
> > > > > > 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 NFSv4, 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.
> > > > > >
> > > > > > Should we add a mechanism to prevent exporting these sorts of
> > > > > > filesystems?
> > > > > >
> > > > > > 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_verify()? We'd
> > > > > > have to add it to a bunch of existing filesystems, but that's fairly
> > > > > > simple to do with an LLM.
> > > > >
> > > > > What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> > > > > explicitly via /etc/exports, so this is under the NFS server admin's
> > > > > control. Is it an attack surface?
> > > > >
> > > >
> > > > Potentially?
> > > >
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > Having an explicit "I want to allow nfsd" flag see ms like it might
> > > > save us some headaches in the future when other filesystems add export
> > > > ops for this sort of filehandle use.
> > >
> > > So we are re-hashing a discussion we had a few months ago (Amir was
> > > involved at least).
> > >
> >
> > Yep, I was lurking on it, but didn't have a lot of input at the time.
> >
> > > I don't think we want to expose cgroupfs via NFS that's super weird.
> > > 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.
> > >
> > > So my preference would be to really sever file handles from the export
> > > mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
> > > use file handles via name_to_handle_at() and open_by_handle_at() without
> > > making them exportable.
> >
> > Agreed. I think we want to make NFS export be a deliberate opt-in
> > decision that filesystem developers make.
>
> No objection, what about ksmbd, AFS, or Ceph?
>
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.
AFS and Ceph in the kernel are clients. AFS isn't reexportable via NFS,
but Ceph is. We'll need to preserve that ability.
--
Jeff Layton <jlayton@kernel.org>
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 PM Jeff Layton <jlayton@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>> 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 delegation 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 lease support be more
>>>>>>>>>>> opt-in, rather than opt-out:
>>>>>>>>>>>
>>>>>>>>>>> For historical reasons, when ->setlease() file_operation is set to NULL,
>>>>>>>>>>> the default is to use the kernel-internal lease implementation. This
>>>>>>>>>>> means that if you want to disable them, you need to explicitly set the
>>>>>>>>>>> ->setlease() file_operation to simple_nosetlease() or the equivalent.
>>>>>>>>>>>
>>>>>>>>>>> This has caused a number of problems over the years as some filesystems
>>>>>>>>>>> have inadvertantly allowed leases to be acquired simply by having left
>>>>>>>>>>> it set to NULL. It would be better if filesystems had to opt-in to lease
>>>>>>>>>>> support, particularly with the advent of directory delegations.
>>>>>>>>>>>
>>>>>>>>>>> This series has sets the ->setlease() operation in a pile of existing
>>>>>>>>>>> local filesystems to generic_setlease() and then changes
>>>>>>>>>>> kernel_setlease() to return -EINVAL when the setlease() operation is not
>>>>>>>>>>> set.
>>>>>>>>>>>
>>>>>>>>>>> With this change, new filesystems will need to explicitly set the
>>>>>>>>>>> ->setlease() operations in order to provide lease and delegation
>>>>>>>>>>> support.
>>>>>>>>>>>
>>>>>>>>>>> I mainly focused on filesystems that are NFS exportable, since NFS and
>>>>>>>>>>> SMB are the main users of file leases, and they tend to end up exporting
>>>>>>>>>>> the same filesystem types. Let me know if I've missed any.
>>>>>>>>>>
>>>>>>>>>> So, what about kernfs and fuse? They seem to be exportable and don't have
>>>>>>>>>> .setlease set...
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, FUSE needs this too. I'll add a patch for that.
>>>>>>>>>
>>>>>>>>> As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
>>>>>>>>> are built on. Do we really expect people to set leases there?
>>>>>>>>>
>>>>>>>>> I guess it's technically a regression since you could set them on those
>>>>>>>>> sorts of files earlier, but people don't usually export kernfs based
>>>>>>>>> filesystems via NFS or SMB, and that seems like something that could be
>>>>>>>>> used to make mischief.
>>>>>>>>>
>>>>>>>>> AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
>>>>>>>>> commit aa8188253474 ("kernfs: add exportfs operations").
>>>>>>>>>
>>>>>>>>> One idea: we could add a wrapper around generic_setlease() for
>>>>>>>>> filesystems like this that will do a WARN_ONCE() and then call
>>>>>>>>> generic_setlease(). That would keep leases working on them but we might
>>>>>>>>> get some reports that would tell us who's setting leases on these files
>>>>>>>>> and why.
>>>>>>>>
>>>>>>>> IMO, you are being too cautious, but whatever.
>>>>>>>>
>>>>>>>> It is not accurate that kernfs filesystems are NFS exportable in general.
>>>>>>>> Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
>>>>>>>>
>>>>>>>> If any application is using leases on cgroup files, it must be some
>>>>>>>> very advanced runtime (i.e. systemd), so we should know about the
>>>>>>>> regression sooner rather than later.
>>>>>>>>
>>>>>>>
>>>>>>> I think so too. For now, I think I'll not bother with the WARN_ONCE().
>>>>>>> Let's just leave kernfs out of the set until someone presents a real
>>>>>>> use-case.
>>>>>>>
>>>>>>>> There are also the recently added nsfs and pidfs export_operations.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Christian? Do you remember?
>>>>>>>>
>>>>>>>
>>>>>>> (cc'ing Chuck)
>>>>>>>
>>>>>>> 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 NFSv4, 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.
>>>>>>>
>>>>>>> Should we add a mechanism to prevent exporting these sorts of
>>>>>>> filesystems?
>>>>>>>
>>>>>>> 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_verify()? We'd
>>>>>>> have to add it to a bunch of existing filesystems, but that's fairly
>>>>>>> simple to do with an LLM.
>>>>>>
>>>>>> What's the active harm in exporting /sys/fs/cgroup ? It has to be done
>>>>>> explicitly via /etc/exports, so this is under the NFS server admin's
>>>>>> control. Is it an attack surface?
>>>>>>
>>>>>
>>>>> Potentially?
>>>>>
>>>>> 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.
>>>>>
>>>>> 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.
>>>>>
>>>>> Having an explicit "I want to allow nfsd" flag see ms like it might
>>>>> save us some headaches in the future when other filesystems add export
>>>>> ops for this sort of filehandle use.
>>>>
>>>> So we are re-hashing a discussion we had a few months ago (Amir was
>>>> involved at least).
>>>>
>>>
>>> Yep, I was lurking on it, but didn't have a lot of input at the time.
>>>
>>>> I don't think we want to expose cgroupfs via NFS that's super weird.
>>>> 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.
>>>>
>>>> So my preference would be to really sever file handles from the export
>>>> mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
>>>> use file handles via name_to_handle_at() and open_by_handle_at() without
>>>> making them exportable.
>>>
>>> Agreed. I think we want to make NFS export be a deliberate opt-in
>>> decision that filesystem developers make.
>>
>> No objection, what about ksmbd, AFS, or Ceph?
>>
>
> 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.
>
> AFS and Ceph in the kernel are clients. AFS isn't reexportable via NFS,
> but Ceph is. We'll need to preserve that ability.
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.
Perhaps the "is_exportable" predicate is better placed separately from
export_ops.
--
Chuck Lever
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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > 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 delegation 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 lease support be more
> > > > > > > > > > > > opt-in, rather than opt-out:
> > > > > > > > > > > >
> > > > > > > > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > > > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > > > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > > > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > > > > > > > >
> > > > > > > > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > > > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > > > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > > > > > > > support, particularly with the advent of directory delegations.
> > > > > > > > > > > >
> > > > > > > > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > > > > > > > local filesystems to generic_setlease() and then changes
> > > > > > > > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > > > > > > > set.
> > > > > > > > > > > >
> > > > > > > > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > > > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > > > > > > > support.
> > > > > > > > > > > >
> > > > > > > > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > > > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > > > > > > > the same filesystem types. Let me know if I've missed any.
> > > > > > > > > > >
> > > > > > > > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > > > > > > > .setlease set...
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > > > > > > > >
> > > > > > > > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > > > > > > > are built on. Do we really expect people to set leases there?
> > > > > > > > > >
> > > > > > > > > > I guess it's technically a regression since you could set them on those
> > > > > > > > > > sorts of files earlier, but people don't usually export kernfs based
> > > > > > > > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > > > > > > > used to make mischief.
> > > > > > > > > >
> > > > > > > > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > > > > > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > > > > > > > >
> > > > > > > > > > One idea: we could add a wrapper around generic_setlease() for
> > > > > > > > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > > > > > > > generic_setlease(). That would keep leases working on them but we might
> > > > > > > > > > get some reports that would tell us who's setting leases on these files
> > > > > > > > > > and why.
> > > > > > > > >
> > > > > > > > > IMO, you are being too cautious, but whatever.
> > > > > > > > >
> > > > > > > > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > > > > > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > > > > > > > >
> > > > > > > > > If any application is using leases on cgroup files, it must be some
> > > > > > > > > very advanced runtime (i.e. systemd), so we should know about the
> > > > > > > > > regression sooner rather than later.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > > > > > > > Let's just leave kernfs out of the set until someone presents a real
> > > > > > > > use-case.
> > > > > > > >
> > > > > > > > > There are also the recently added nsfs and pidfs export_operations.
> > > > > > > > >
> > > > > > > > > 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.
> > > > > > > > >
> > > > > > > > > Christian? Do you remember?
> > > > > > > > >
> > > > > > > >
> > > > > > > > (cc'ing Chuck)
> > > > > > > >
> > > > > > > > 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 NFSv4, 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.
> > > > > > > >
> > > > > > > > Should we add a mechanism to prevent exporting these sorts of
> > > > > > > > filesystems?
> > > > > > > >
> > > > > > > > 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_verify()? We'd
> > > > > > > > have to add it to a bunch of existing filesystems, but that's fairly
> > > > > > > > simple to do with an LLM.
> > > > > > >
> > > > > > > What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> > > > > > > explicitly via /etc/exports, so this is under the NFS server admin's
> > > > > > > control. Is it an attack surface?
> > > > > > >
> > > > > >
> > > > > > Potentially?
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > Having an explicit "I want to allow nfsd" flag see ms like it might
> > > > > > save us some headaches in the future when other filesystems add export
> > > > > > ops for this sort of filehandle use.
> > > > >
> > > > > So we are re-hashing a discussion we had a few months ago (Amir was
> > > > > involved at least).
> > > > >
> > > >
> > > > Yep, I was lurking on it, but didn't have a lot of input at the time.
> > > >
> > > > > I don't think we want to expose cgroupfs via NFS that's super weird.
> > > > > 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.
> > > > >
> > > > > So my preference would be to really sever file handles from the export
> > > > > mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
> > > > > use file handles via name_to_handle_at() and open_by_handle_at() without
> > > > > making them exportable.
> > > >
> > > > Agreed. I think we want to make NFS export be a deliberate opt-in
> > > > decision that filesystem developers make.
> > >
> > > No objection, what about ksmbd, AFS, or Ceph?
> > >
> >
> > 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.
> >
> > AFS and Ceph in the kernel are clients. AFS isn't reexportable via NFS,
> > but Ceph is. We'll need to preserve that ability.
>
> 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.
>
> Perhaps the "is_exportable" predicate is better placed separately from
> export_ops.
>
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?
--
Jeff Layton <jlayton@kernel.org>
On Tue, Jan 13, 2026 at 9:54 AM Christian Brauner <brauner@kernel.org> 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 PM Jeff Layton <jlayton@kernel.org> wrote:
> > > > > >
> > > > > > 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 delegation 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 lease support be more
> > > > > > > > opt-in, rather than opt-out:
> > > > > > > >
> > > > > > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > > > > > the default is to use the kernel-internal lease implementation. This
> > > > > > > > means that if you want to disable them, you need to explicitly set the
> > > > > > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > > > > > >
> > > > > > > > This has caused a number of problems over the years as some filesystems
> > > > > > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > > > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > > > > > support, particularly with the advent of directory delegations.
> > > > > > > >
> > > > > > > > This series has sets the ->setlease() operation in a pile of existing
> > > > > > > > local filesystems to generic_setlease() and then changes
> > > > > > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > > > > > set.
> > > > > > > >
> > > > > > > > With this change, new filesystems will need to explicitly set the
> > > > > > > > ->setlease() operations in order to provide lease and delegation
> > > > > > > > support.
> > > > > > > >
> > > > > > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > > > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > > > > > the same filesystem types. Let me know if I've missed any.
> > > > > > >
> > > > > > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > > > > > .setlease set...
> > > > > > >
> > > > > >
> > > > > > Yes, FUSE needs this too. I'll add a patch for that.
> > > > > >
> > > > > > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > > > > > are built on. Do we really expect people to set leases there?
> > > > > >
> > > > > > I guess it's technically a regression since you could set them on those
> > > > > > sorts of files earlier, but people don't usually export kernfs based
> > > > > > filesystems via NFS or SMB, and that seems like something that could be
> > > > > > used to make mischief.
> > > > > >
> > > > > > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > > > > > commit aa8188253474 ("kernfs: add exportfs operations").
> > > > > >
> > > > > > One idea: we could add a wrapper around generic_setlease() for
> > > > > > filesystems like this that will do a WARN_ONCE() and then call
> > > > > > generic_setlease(). That would keep leases working on them but we might
> > > > > > get some reports that would tell us who's setting leases on these files
> > > > > > and why.
> > > > >
> > > > > IMO, you are being too cautious, but whatever.
> > > > >
> > > > > It is not accurate that kernfs filesystems are NFS exportable in general.
> > > > > Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
> > > > >
> > > > > If any application is using leases on cgroup files, it must be some
> > > > > very advanced runtime (i.e. systemd), so we should know about the
> > > > > regression sooner rather than later.
> > > > >
> > > >
> > > > I think so too. For now, I think I'll not bother with the WARN_ONCE().
> > > > Let's just leave kernfs out of the set until someone presents a real
> > > > use-case.
> > > >
> > > > > There are also the recently added nsfs and pidfs export_operations.
> > > > >
> > > > > 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.
> > > > >
> > > > > Christian? Do you remember?
> > > > >
> > > >
> > > > (cc'ing Chuck)
> > > >
> > > > 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 NFSv4, 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.
> > > >
> > > > Should we add a mechanism to prevent exporting these sorts of
> > > > filesystems?
> > > >
> > > > 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_verify()? We'd
> > > > have to add it to a bunch of existing filesystems, but that's fairly
> > > > simple to do with an LLM.
> > >
> > > What's the active harm in exporting /sys/fs/cgroup ? It has to be done
> > > explicitly via /etc/exports, so this is under the NFS server admin's
> > > control. Is it an attack surface?
> > >
> >
> > Potentially?
> >
> > 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.
> >
> > 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.
> >
> > Having an explicit "I want to allow nfsd" flag see ms like it might
> > save us some headaches in the future when other filesystems add export
> > ops for this sort of filehandle use.
>
> So we are re-hashing a discussion we had a few months ago (Amir was
> involved at least).
>
> I don't think we want to expose cgroupfs via NFS that's super weird.
> 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.
>
> So my preference would be to really sever file handles from the export
> mechanism so that we can allow stuff like pidfs and nsfs and cgroupfs to
> use file handles via name_to_handle_at() and open_by_handle_at() without
> making them exportable.
>
> Somehow I thought that Amir had already done that work a while ago but
> maybe it was really just about name_to_handle_at() and not also
> open_by_handle_at()...
I don't recall doing anything except talking ;)
How about something like this to safeguard against exporting
the new pidfs/nsfs.
Regarding cgroupfs, we could either use a EXPORT_OP_ flag
or maybe it should have a custom open/permission as well?
Thanks,
Amir.
On Fri, Jan 09, 2026 at 07:52:57PM +0100, Amir Goldstein wrote:
> On Thu, Jan 8, 2026 at 7:57 PM Jeff Layton <jlayton@kernel.org> wrote:
> >
> > 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 delegation 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 lease support be more
> > > > opt-in, rather than opt-out:
> > > >
> > > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > > the default is to use the kernel-internal lease implementation. This
> > > > means that if you want to disable them, you need to explicitly set the
> > > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > > >
> > > > This has caused a number of problems over the years as some filesystems
> > > > have inadvertantly allowed leases to be acquired simply by having left
> > > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > > support, particularly with the advent of directory delegations.
> > > >
> > > > This series has sets the ->setlease() operation in a pile of existing
> > > > local filesystems to generic_setlease() and then changes
> > > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > > set.
> > > >
> > > > With this change, new filesystems will need to explicitly set the
> > > > ->setlease() operations in order to provide lease and delegation
> > > > support.
> > > >
> > > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > > SMB are the main users of file leases, and they tend to end up exporting
> > > > the same filesystem types. Let me know if I've missed any.
> > >
> > > So, what about kernfs and fuse? They seem to be exportable and don't have
> > > .setlease set...
> > >
> >
> > Yes, FUSE needs this too. I'll add a patch for that.
> >
> > As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> > are built on. Do we really expect people to set leases there?
> >
> > I guess it's technically a regression since you could set them on those
> > sorts of files earlier, but people don't usually export kernfs based
> > filesystems via NFS or SMB, and that seems like something that could be
> > used to make mischief.
> >
> > AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> > commit aa8188253474 ("kernfs: add exportfs operations").
> >
> > One idea: we could add a wrapper around generic_setlease() for
> > filesystems like this that will do a WARN_ONCE() and then call
> > generic_setlease(). That would keep leases working on them but we might
> > get some reports that would tell us who's setting leases on these files
> > and why.
>
> IMO, you are being too cautious, but whatever.
>
> It is not accurate that kernfs filesystems are NFS exportable in general.
> Only cgroupfs has KERNFS_ROOT_SUPPORT_EXPORTOP.
>
> If any application is using leases on cgroup files, it must be some
> very advanced runtime (i.e. systemd), so we should know about the
> regression sooner rather than later.
>
> There are also the recently added nsfs and pidfs export_operations.
>
> 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.
>
> Christian? Do you remember?
I don't think it does.
On Thu 08-01-26 13:56:57, Jeff Layton wrote:
> 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 delegation 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 lease support be more
> > > opt-in, rather than opt-out:
> > >
> > > For historical reasons, when ->setlease() file_operation is set to NULL,
> > > the default is to use the kernel-internal lease implementation. This
> > > means that if you want to disable them, you need to explicitly set the
> > > ->setlease() file_operation to simple_nosetlease() or the equivalent.
> > >
> > > This has caused a number of problems over the years as some filesystems
> > > have inadvertantly allowed leases to be acquired simply by having left
> > > it set to NULL. It would be better if filesystems had to opt-in to lease
> > > support, particularly with the advent of directory delegations.
> > >
> > > This series has sets the ->setlease() operation in a pile of existing
> > > local filesystems to generic_setlease() and then changes
> > > kernel_setlease() to return -EINVAL when the setlease() operation is not
> > > set.
> > >
> > > With this change, new filesystems will need to explicitly set the
> > > ->setlease() operations in order to provide lease and delegation
> > > support.
> > >
> > > I mainly focused on filesystems that are NFS exportable, since NFS and
> > > SMB are the main users of file leases, and they tend to end up exporting
> > > the same filesystem types. Let me know if I've missed any.
> >
> > So, what about kernfs and fuse? They seem to be exportable and don't have
> > .setlease set...
> >
>
> Yes, FUSE needs this too. I'll add a patch for that.
>
> As far as kernfs goes: AIUI, that's basically what sysfs and resctrl
> are built on. Do we really expect people to set leases there?
>
> I guess it's technically a regression since you could set them on those
> sorts of files earlier, but people don't usually export kernfs based
> filesystems via NFS or SMB, and that seems like something that could be
> used to make mischief.
I agree exporting kernfs based filesystem doesn't make a huge amount of
sense.
> AFAICT, kernfs_export_ops is mostly to support open_by_handle_at(). See
> commit aa8188253474 ("kernfs: add exportfs operations").
>
> One idea: we could add a wrapper around generic_setlease() for
> filesystems like this that will do a WARN_ONCE() and then call
> generic_setlease(). That would keep leases working on them but we might
> get some reports that would tell us who's setting leases on these files
> and why.
Yeah, this makes sense at least for some transition period so that we
faster learn if our judgement about sane / insane lease use was wrong.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
On Thu, 08 Jan 2026 12:12:55 -0500, Jeff Layton wrote:
> Yesterday, I sent patches to fix how directory delegation 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 lease support be more
> opt-in, rather than opt-out:
>
> For historical reasons, when ->setlease() file_operation is set to NULL,
> the default is to use the kernel-internal lease implementation. This
> means that if you want to disable them, you need to explicitly set the
> ->setlease() file_operation to simple_nosetlease() or the equivalent.
>
> [...]
Applied to the vfs-7.0.leases branch of the vfs/vfs.git tree.
Patches in the vfs-7.0.leases branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-7.0.leases
[01/24] fs: add setlease to generic_ro_fops and read-only filesystem directory operations
https://git.kernel.org/vfs/vfs/c/ca4388bf1d9e
[02/24] affs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/663cdef61a27
[03/24] btrfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/f9688474e413
[04/24] erofs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/f8902d3df893
[05/24] ext2: add setlease file operation
https://git.kernel.org/vfs/vfs/c/ccdc2e0569f5
[06/24] ext4: add setlease file operation
https://git.kernel.org/vfs/vfs/c/20747a2a29c6
[07/24] exfat: add setlease file operation
https://git.kernel.org/vfs/vfs/c/b8ca02667552
[08/24] f2fs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/9e2ac6ddb397
[09/24] fat: add setlease file operation
https://git.kernel.org/vfs/vfs/c/a9acc8422ffb
[10/24] gfs2: add a setlease file operation
https://git.kernel.org/vfs/vfs/c/3b514c333390
[11/24] jffs2: add setlease file operation
https://git.kernel.org/vfs/vfs/c/c275e6e7c085
[12/24] jfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/7dd596bb35e5
[13/24] nilfs2: add setlease file operation
https://git.kernel.org/vfs/vfs/c/f46bb13dc5d9
[14/24] ntfs3: add setlease file operation
https://git.kernel.org/vfs/vfs/c/6aaa1d6337b5
[15/24] ocfs2: add setlease file operation
https://git.kernel.org/vfs/vfs/c/f15d3150279d
[16/24] orangefs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/136b43aa4b16
[17/24] overlayfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/94a3f60af5dc
[18/24] squashfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/dfd8676efe43
[19/24] tmpfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/f5a3446be277
[20/24] udf: add setlease file operation
https://git.kernel.org/vfs/vfs/c/dbe8d57d1483
[21/24] ufs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/545b4144d804
[22/24] xfs: add setlease file operation
https://git.kernel.org/vfs/vfs/c/6163b5da2f5e
[23/24] filelock: default to returning -EINVAL when ->setlease operation is NULL
https://git.kernel.org/vfs/vfs/c/2b10994be716
[24/24] fs: remove simple_nosetlease()
https://git.kernel.org/vfs/vfs/c/51e49111c00b
On Thu, Jan 08, 2026 at 12:12:55PM -0500, Jeff Layton wrote: > I mainly focused on filesystems that are NFS exportable, since NFS and > SMB are the main users of file leases, and they tend to end up exporting > the same filesystem types. Let me know if I've missed any. Series looks sane and I don't see any obvious gaps. Acked-by: Al Viro <viro@zeniv.linux.org.uk>
On Thu, Jan 08, 2026 at 12:12:55PM -0500, Jeff Layton wrote: > I mainly focused on filesystems that are NFS exportable, since NFS and > SMB are the main users of file leases, and they tend to end up exporting > the same filesystem types. Let me know if I've missed any. > > [1]: https://lore.kernel.org/linux-fsdevel/20260107-setlease-6-19-v1-0-85f034abcc57@kernel.org/ That seems reasonable, and I like the approach here (without having the time to review every change right now): Acked-by: Christoph Hellwig <hch@lst.de> If it turns out we have people use leases on other file systems we'll have to wire up a few more instance as needed, but I think your initial set makes sense.
© 2016 - 2026 Red Hat, Inc.