Ok, you were definitely under memory pressure, and yes, it looks like the
exact same bug on ppc64 - access to a pointer that is two poointers offset
down from NULL.
Yes.
I actually like my second patch better - it looks simpler, and it means
that the rules for filesystems using d_compare() are a bit clearer: at
least we'll only pass them dentries to look at that haven't gone through
d_drop (and we do hold dentry->d_lock that serializes all of that).
So here it is again (I sent it out just minutes ago, but you weren't on
that cc, you must have picked this up off the kernel list)
NOTE! Totally untested patch! It looks sane and really obvious, but maybe
it has some insane and non-obvious bug.
Linus
---
fs/dcache.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/dcache.c b/fs/dcache.c
index 80e9395..e7a1a99 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1395,6 +1395,10 @@ struct dentry * __d_lookup(struct dentry * parent, struct qstr * name)
if (dentry->d_parent != parent)
goto next;
+ /* non-existing due to RCU? */
+ if (d_unhashed(dentry))
+ goto next;
+
/*
* It is safe to compare names since d_move() cannot
* change the qstr (protected by d_lock).
@@ -1410,10 +1414,8 @@ struct dentry * __d_lookup(struct dentry * parent, struct qstr * name)
goto next;
}
- if (!d_unhashed(dentry)) {
- atomic_inc(&dentry->d_count);
- found = dentry;
- }
+ atomic_inc(&dentry->d_count);
+ found = dentry;
spin_unlock(&dentry->d_lock);
break;
next:
--
