Hi Christoph, On Fri, 27 May 2011, Christoph Hellwig wrote: > Sage, > > this series still leaves a lot of dentry_unhash callsites around, > can you submit some more patches to clan up after it? > > - bfs, sysv, jffs2, jfs, logfs, nilfs2, ubifs and ufs are plain old > unix filesystems and should not have a problem. > - reiserfs is a bit special but really shouldn't need it, also it has > a local copy of vfs_rmdir that needs the call removed as well. > - udf also seems to have normal unix semantics > - same for omfs > - ecryptfs just passed down requests to the lower fs and thus almost > certainly doesn't need it. > - hfs and hfsplus don't care > - hostsfs doesn't really either > > Cced some more maintainers. In the end each callsite of dentry_unhash > really should have a comment why it's needed or at least why we're > unsure about it. I'm going through and looking at all the remaining callers now. I just want to verify one thing with you to make sure my understanding is 100% correct: as long as the file system isn't looking at whether the dentry is hashed or unhashed after the dentry_unhash() call, that implies that there are no issues with lingering directory references, right? Because a racing lookup getting into the directory (which dentry_unhash would prevent) isn't any different from a prior reference if the fs isn't checking the hashed status. If that's the case, it looks like ncpfs is the main one that needs it. hpfs does something really weird when close to ENOSPC and needs it for that, but doesn't appear to for rmdir and dir rename. autofs4 I'm scared to touch. Everyone else (9p, affs, afs, coda, configfs, fat, fuse, and minix) I think I can remove. Does that mesh with your understanding? Thanks! sage -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
