b=5687,5210

A workaround for the crash in ll_unhash_aliases on 2.6.

The 2.6 lookup code is now lockless (thanks to the RCU machinations), which
allows it to race with the unhashing in ll_unhash_aliases.  The 2.6 __d_drop
doesn't leave the list head ->pprev in a safe state, so the next pass through
this loop (which tries to re-hash it after we lose the dput race), would crash.

For the record, it looks like the kernel's own d_prune_aliases is broken in
the very same way, except that instead of crashing immediately, it just leaves
the d_hash pointers poisoned for someone else to crash on.

diff --git a/lustre/ChangeLog b/lustre/ChangeLog
index 000b5c6..349f5ba 100644 (file)
--- a/lustre/ChangeLog
+++ b/lustre/ChangeLog
@@ -26,6 +26,7 @@ tbd         Cluster File Systems, Inc. <info@clusterfs.com>
        - don't LASSERT in ll_release on NULL lld with NFS export (4655, 5760)
        - hold NS lock when calling handle_ast_error->del_waiting_lock (5746)
        - fix setattr mtime regression from lovcleanup merge (4829, 5669)
+       - workaround for 2.6 crash in ll_unhash_aliases (5687, 5210)
        * miscellania
        - service request history (4965)
        - put {ll,lov,osc}_async_page structs in a single slab (4699)

diff --git a/lustre/llite/dcache.c b/lustre/llite/dcache.c
index 2909e1a..c19e289 100644 (file)
--- a/lustre/llite/dcache.c
+++ b/lustre/llite/dcache.c
@@ -180,6 +180,9 @@ restart:
                                dentry->d_inode);
                         dget_locked(dentry);
                         __d_drop(dentry);
+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0))
+                        INIT_HLIST_NODE(&dentry->d_hash);
+#endif
                         spin_unlock(&dcache_lock);
                         dput(dentry);
                         goto restart;