lkml.org 
[lkml]   [2004]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dentry bloat.
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 14:03    [W:0.089 / U:0.640 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site