Messages in this thread | | | Date | Tue, 11 May 2004 10:47:57 +0530 | From | Maneesh Soni <> | Subject | Re: 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/
| |