lkml.org 
[lkml]   [2004]   [May]   [11]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateTue, 11 May 2004 10:56:58 +0530
FromManeesh Soni <>
SubjectRe: dentry bloat.
On Sun, May 09, 2004 at 03:27:20PM -0700, Andrew Morton wrote:
> viro@parcelfarce.linux.theplanet.co.uk wrote:
> >
> > On Sun, May 09, 2004 at 09:03:16PM +0530, Dipankar Sarma wrote:
> > 
> > > 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()
> > 
> > Not really.  A miss could result in getting another dentry allocated
> > for the same e.g. directory, which is *NOT* harmless at all.
> 
> The d_bucket logic does look a bit odd.
> 
> 		dentry = hlist_entry(node, struct dentry, d_hash);
> 
> 		/* if lookup ends up in a different bucket 
> 		 * due to concurrent rename, fail it
> 		 */
> 		if (unlikely(dentry->d_bucket != head))
> 			break;
> 
> 		/*
> 		 * We must take a snapshot of d_move_count followed by
> 		 * read memory barrier before any search key comparison 
> 		 */
> 		move_count = dentry->d_move_count;
> 
> There is a window between the d_bucket test and sampling of d_move_count. 
> What happens if the dentry gets moved around in there?
> 
> Anyway, regardless of that, it is more efficient to test d_bucket _after_
> performing the hash comparison.  And it seems saner to perform the d_bucket
> check when things are pinned down by d_lock.
> 

This should be fine. Earlier d_bucket check was done before "continue" as the 
lookup used to loop infinetly. The reason for infinite looping was that lookup 
going to a different hash bucket due to concurrent d_move and not finding
the list head from where it started.

After introduction of hlist, there is less chance of lookup looping
infinitely even if it is moved to a different hash bucket as hlist ends with 
NULL.


But I still see theoritical possibilty of increased looping. Double rename can 
keep putting lookup back at the head of hash chain and hlist end is never seen.



-- 
Maneesh Soni
IBM Linux Technology Center, 
IBM India Software Lab, Bangalore.
Phone: +91-80-5044999 email: maneesh@in.ibm.com
http://lse.sourceforge.net/
-
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