On Thu, Jun 29, 2017 at 10:35:51AM -0400, J. Bruce Fields wrote: > On Wed, Jun 28, 2017 at 09:59:40PM -0700, Darrick J. Wong wrote: > > AFAICT, i_generation == 0 in XFS and btrfs is just as valid as any other > > number. There is no special casing of zero in either filesystem. > > > > So now, my curiosity intrigued, I surveyed all the Linux filesystems > > that can export to NFS. I see that there are actually quite a few fs > > (ext[2-4], exofs, efs, fat, jfs, f2fs, isofs, nilfs2, reiserfs, udf, > > ufs) that treat zero as a special value meaning "ignore generation > > check"; others (xfs, btrfs, fuse, ntfs, ocfs2) that don't consider zero > > special and always require a match; and still others (affs, befs, ceph, > > gfs2, jffs2, squashfs) that don't check at all. > > > > That to mean strongly suggests that more research is necessary to figure > > out why some of the filesystems that support i_generation reserve zero > > as a special value to disable generation checks and why others always > > require an exact match. Until we can recapture why things are they way > > they are, it doesn't make much sense to have a helper that only applies > > to half the filesystems. > > From a quick look at ext2; correct me if I got anything wrong: > > - it looks like this is *only* used by NFS fh->inode lookups, > there's not some other internal use for this special case. > - filehandles are never encoded with i_generation 0, so will > never be returned to clients. > > So, this could only ever be used by an NFS client. But the only NFS > client that could ever use it would be a non-standard client that knew > this special feature of these particular filesystems. > > Sounds like at most a slightly useful tool for malicious clients > attempting filehandle-guessing attacks. > > I'm probably missing something. Was there ever a version of NFS (or more generally callers of the exportfs code) that couldn't deal with i_generation in the file handle, and therefore we invented this generation hack to work around the loss of the generation information? There's a comment in xfs_fs_encode_fh about not supporting 64bit inodes with subtree_check (which seems to require one ino/gen pair for the file and a second pair for the file's parent) on NFSv2 because v2 doesn't provide enough space for all the file handle information, but that's the furthest I got with lazy-mining the git history. :) --D > > --b.
