On Wed, 2026-01-21 at 21:34 +1100, NeilBrown wrote: > On Wed, 21 Jan 2026, Christoph Hellwig wrote: > > > > > > > > > It took me a while to sift through the code/patches/comments and come to > > > this understanding and I apologise if I wasn't as clear earlier. But > > > my intuition was always that file handle stability was never the real > > > issue, and maintainer choice was. Hence my rejection of the > > > "STABLE_HANDLES" name. > > > > Why do you keep ignoring the fat that the stable handles are really > > important for anyone wanting to actually use them for their original > > storage purpose, be that for knfsd, a userland nfs damon, or other > > storage applications in userspace despite explaining this countless > > times? > > > > It isn't that I don't think they are important. It is that I think they > are universally provided (when not connectable). > If we add an EXPORT_OP_STABLE_FILEHANDLES flag, I believe we would need to > set it on every export_operations structure. So what would be the > point? >
I see your point. Using your definitions, stability is not a problem for Linux filesystems. The filehandles generally don't change after they have been established. Uniqueness however _is_ a problem as we can end up with valid handles for files that have been recreated across a reboot with some filesystems (esp. "synthetic" ones like cgroupfs, pidfs, etc.). Naming the flag STABLE conflates the two. In an earlier email, HCH said: > We'll still need a stable handles flag, and expose it to userspace > to avoid applications being tricked into using broken non-stable > file handles. We should have caught that when they were added, but > didn't unfortunately. > If we assume he meant "unique handles" flag, then I think we're all mostly in agreement here. As far as this patchset goes: what if we were to just rename EXPORT_OP_STABLE_HANDLES to EXPORT_OP_UNIQUE_HANDLES (and clean up the documentation), since that's the main issue for existing filesystems. It would be fairly simple to advertise handle uniqueness using statx or something. Alternately, instead of denying access to these filesystems, we could just fix these filesystems to create unique handles (a'la random i_generation value or something similar). That should mostly prevent filehandles from being reusable across a reboot on these filesystems. That would leave cgroupfs and the like exportable via nfsd, but as you point out, we can't deny export by userland servers. If people want to do this kind of crazy stuff, maybe we shouldn't deny them after all. -- Jeff Layton <[email protected]>
