There's a fun problem - for all the complaints about evil, crude VFS exclusion not letting the smart filesystem developers Do It Right(tm), NFS has a homegrown kinda-sorta rwsem, with delayed unlinks being readers and lookups - writers. IOW, nfs_block_sillyrename() still yields lookup/lookup exclusion, even with ->i_mutex replaced with rwsem and ->lookup() calls happening in parallel. What's more, the thing is very much writer(==lookup)-starving. What kind of ordering do we really want there? Existing variant is very crude - lookups (along with readdir and atomic_open) are writers, delayed unlinks - readers, and there's no fairness whatsoever; if delayed unlink comes during lookup, it is put on a list and once lookup is done, everything on that list is executed. Moreover, any unlinks coming during the execution of those are executed immediately. And no lookup (in that directory) is allowed until there's no unlinks in progress. Creating a storm of delayed unlinks isn't hard - open-and-unlink a lot, then exit and you've got it... Suggestions? Right now my local tree has nfs_lookup() and nfs_readdir() run with directory locked shared. And they are still serialized by the damn ->silly_count ;-/ Incidentally, why does nfs_complete_unlink() recheck ->d_flags? The caller of ->d_iput() is holding the only reference to dentry; who and what could possibly clear DCACHE_NFSFS_RENAMED between the checks in nfs_dentry_iput() and nfs_complete_unlink()? -- 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
