> > > > > Simpler: if alias and our dentry share the parent, it's locked and > > > > > we can rename without s_vfs_rename_mutex. If they do not, walk the > > > > > tree under alias, unhash all non-directories and kill all directories. > > > > > > > > What do you mean by "killing directories"? Unhashing the inode? > > > > > > > > Are these OK, without holding i_mutex on alias and descendents? > > > > > > Only dcache locking is needed for unhashing dentries (which is what > > > we do to non-directories). For directories, we should silently > > > unhash inodes and make sure that all future operations on those inodes > > > would fail. Up to filesystem how you do that. Additionally, make > > > sure that revalidation fails on those suckers. > > > > OK, what about operations currently in progress on those directories > > and files? Is there no way these can cause trouble? > > We need variants of d_move() and d_rehash() that do not take dcache_lock, > so that such fs would use them under dcache_lock, then check if parent > is dead and do the same kind of unhashing/killing if it is. I.e. > pretend that we'd won the race and killer lookup came later. I mostly see how that would work for lookup, but in case of rename the d_move() is done by the VFS. So that seems to need surgery as well. Miklos - 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
