Tested using dcachebench and hevy rename test.
http://lse.sourceforge.net/locking/dcache/rename_test/

While going over dcache code, I realized that d_bucket which was introduced
to prevent hash chain traversals from going into an infinite loop earlier,
is no longer necessary.  Originally, when RCU based lock-free lookup was
first introduced, dcache hash chains used list_head.  Hash chain traversal
was terminated when dentry->next reaches the list_head in the hash bucket. 
However, if renames happen during a lock-free lookup, a dentry may move to
different bucket and subsequent hash chain traversal from there onwards may
not see the list_head in the original bucket at all.  In fact, this would
result in the list_head in the bucket interpreted as a list_head in dentry
and bad things will happen after that.  Once hlist based hash chains were
introduced in dcache, the termination condition changed and lock-free
traversal would be safe with NULL pointer based termination of hlists.
This means that d_bucket check is no longer required.

There still exist some theoritical livelocks like a dentry getting
continuously moving and lock-free look-up never terminating.  But that
isn't really any worse that what we have.  In return for these changes, we
reduce the dentry size by the size of a pointer.  That should make akpm and
mpm happy.
Signed-off-by: Dipankar Sarma <dipankar@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>