Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
Hello: This series was applied to jaegeuk/f2fs.git (dev) by Christian Brauner : On Thu, 08 Jan 2026 12:12:55 -0500 you 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. > > [...] Here is the summary with links: - [f2fs-dev,01/24] fs: add setlease to generic_ro_fops and read-only filesystem directory operations https://git.kernel.org/jaegeuk/f2fs/c/ca4388bf1d9e - [f2fs-dev,02/24] affs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/663cdef61a27 - [f2fs-dev,03/24] btrfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/f9688474e413 - [f2fs-dev,04/24] erofs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/f8902d3df893 - [f2fs-dev,05/24] ext2: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/ccdc2e0569f5 - [f2fs-dev,06/24] ext4: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/20747a2a29c6 - [f2fs-dev,07/24] exfat: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/b8ca02667552 - [f2fs-dev,08/24] f2fs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/9e2ac6ddb397 - [f2fs-dev,09/24] fat: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/a9acc8422ffb - [f2fs-dev,10/24] gfs2: add a setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/3b514c90 - [f2fs-dev,11/24] jffs2: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/c275e6e7c085 - [f2fs-dev,12/24] jfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/7dd596bb35e5 - [f2fs-dev,13/24] nilfs2: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/f46bb13dc5d9 - [f2fs-dev,14/24] ntfs3: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/6aaa1d6337b5 - [f2fs-dev,15/24] ocfs2: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/f15d3150279d - [f2fs-dev,16/24] orangefs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/136b43aa4b16 - [f2fs-dev,17/24] overlayfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/94a3f60af5dc - [f2fs-dev,18/24] squashfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/dfd8676efe43 - [f2fs-dev,19/24] tmpfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/f5a3446be277 - [f2fs-dev,20/24] udf: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/dbe8d57d1483 - [f2fs-dev,21/24] ufs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/545b4144d804 - [f2fs-dev,22/24] xfs: add setlease file operation https://git.kernel.org/jaegeuk/f2fs/c/6163b5da2f5e - [f2fs-dev,23/24] filelock: default to returning -EINVAL when ->setlease operation is NULL https://git.kernel.org/jaegeuk/f2fs/c/2b10994be716 - [f2fs-dev,24/24] fs: remove simple_nosetlease() https://git.kernel.org/jaegeuk/f2fs/c/51e49111c00b You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 > > > 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 > > 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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.. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Wed, Jan 14, 2026, at 9:14 AM, Amir Goldstein wrote: > On Wed, Jan 14, 2026 at 2:41 PM Jeff Layton wrote: > 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? I think we need to be careful. tmpfs filehandles align quite well with the traditional definition of persistent filehandles. tmpfs filehandles live as long as tmpfs files do, and that is all that is required to be considered "persistent". -- Chuck Lever ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote: > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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? ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Wed, Jan 14, 2026 at 2:41 PM 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 > > > 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Wed, 14 Jan 2026 10:34:04 +0100 Amir Goldstein wrote: > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig 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 ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 > > 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 ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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
> > > > > > > > > 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
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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) ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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 act
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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.
>>>
>>> Shou
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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
> > > > > > > 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 un
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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 nf
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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
> explici
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 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
___
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Fri, 2026-01-09 at 19:52 +0100, Amir Goldstein wrote:
> On Thu, Jan 8, 2026 at 7:57 PM 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.
> >
> > 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
___
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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/3b514c90 [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 ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Fri, Jan 09, 2026 at 07:52:57PM +0100, Amir Goldstein wrote:
> On Thu, Jan 8, 2026 at 7:57 PM 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.
> >
> > 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.
___
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
On Thu, Jan 8, 2026 at 7:57 PM 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.
>
> 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.
___
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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
SUSE Labs, CR
___
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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 ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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/[email protected]/ That seems reasonable, and I like the approach here (without having the time to review every change right now): Acked-by: Christoph Hellwig 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. ___ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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/[email protected]/
> >
> > Signed-off-by: Jeff Layton
> > ---
> > 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 |
Re: [f2fs-dev] [PATCH 00/24] vfs: require filesystems to explicitly opt-in to lease support
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/[email protected]/ > > Signed-off-by: Jeff Layton > --- > 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/ora
