lkml.org 
[lkml]   [2004]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dentry bloat.
On Tue, May 11, 2004 at 12:09:25AM +0530, Dipankar Sarma wrote:
> On Sun, May 09, 2004 at 11:17:12PM +0100, 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.
>
> AFAICS, a miss in __d_lookup would result in a repeat lookup
> under dcache_lock in which case we are safe or real_lookup()
> which in turn does another lookup with dcache_lock. Is there
> a path that I am missing here ?


Actually, real_lookup is done with parent's i_sem (avoiding rename is the
same directory) and it also uses rename_lock (seqence lock) which provides
protection against d_move. (real_lookup() --> d_lookup() --> __d_lookup()).

So as real_lookup() does repeat the cached lookup, I don't see any chance
of missing a hashed dentry and allocating one more dentry with the same name.

Thanks
Maneesh

--
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 14:03    [W:0.117 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site