![]() | ||||||||||
Messages in this thread |
On Sun, May 09, 2004 at 09:28:46AM +0200, Manfred Spraul wrote: > What's the prupose of d_move_count? > AFAICS it protects against a double rename: first to different bucket, > then back to original bucket. This changes the position of the dentry in > the hash chain and a concurrent lookup would skip entries. > d_lock wouldn't prevent that. Actually, what may happen is that since the dentries are added in the front, a double move like that would result in hash chain traversal looping. Timing dependent and unlikely, but d_move_count avoided that theoritical possibility. It is not about skipping dentries which is safe because a miss would result in a real_lookup() anyway. If we do the comparison within d_lock, then atleast we are guaranteed to get the right file. The remaining question is whether we violate POSIX rename semantics in some twisted way. > But I think d_bucket could be removed: for __d_lookup the test appears > to be redundant with the d_move_count test. The remaining users are not > performance critical, they could recalculate the bucket from d_parent > and d_name.hash. Yes, afaics, d_move_count can effectively be used to work around the possibility of the dentry moving to a different hash bucket. Thanks Dipankar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-03-22 13:03 [from the cache] ©2003-2008 | ||||||||||