On Mon, Apr 15, 2024 at 12:40:36PM -0700, Darrick J. Wong wrote: > True, libhandle is a very nice wrapper for the kernel ioctls. I wish > Linux projects did that more often. But suppose you're calling the > ioctls directly without libhandle and mess it up? The you get different inodes back. Not really any different from pointing your path name based code to the wrong fs or directory, is it? > > In theory no one cares as all operations work just fine with disconnected > > dentries, and exportfs_decode_fh doesn't do these checks unless the > > accpetable parameter is passed to it. The real question is why we (which > > in this case means 15 years younger me) decided back then we want this > > checking for XFS handle operations? I can't really think of one > > right now.. > > Me neither. Though at this point there are a lot of filesystems that > implement ->get_parent, so I think removing XFS's will need a discussion > at least on linux-xfs, if not fsdevel. In the meantime, getparents can > do minimal validation + iget for now and if it makes sense to port it > back to xfs_khandle_to_dentry, I can do that easily. Uhh, I'm not advocating for removing ->get_parent at all. We actually do need that for security on NFS, where the file handles are used undernath pathname based operations. And it turns out my previous analysis wasn't quite sport on. The exportfs code always reconnects directories, because we basically have to, not connecting them would make the VFS locking scheme not work. But as we never generate the file handles that encode the parent we already never connect files to their parent directory anyway. OTOH we should be able to optimize ->get_parent a bit with parent pointers, as we can find the name in the parent directory for a directory instead of doing linear scans in the parent directory. (for non-directory files we currenty don't fully connect anwyay)
