It turns out that the problem wasn't as obscure as I was afraid it might
be. Basically it stems from the addition of d_set_d_op(), which as an
optimization uses flags in d_flags to indicate the presence or absence
of the various ops. The problem is that we may be replacing one set of
ops with another, which was in fact the case in the call from the cgroup
code. (We might even be setting d_op to NULL.) If the new set doesn't
implement everything that the old one did, we'll have bits set in
d_flags that correspond to NULL function pointers.
The fix is simply to clear our bits when we change d_op.
Patch:
When we change dentry->d_op we need to clear our flags first, just in case
the new set (which may even be NULL) doesn't implement everything the
old set did.
Signed-off-by: Frank Mayhar <fmayhar@xxxxxxxxxx>
---
fs/dcache.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/dcache.c b/fs/dcache.c
index b055536..bd5e1fe 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1358,6 +1358,14 @@ EXPORT_SYMBOL(d_alloc);
void d_set_d_op(struct dentry *dentry, const struct dentry_operations *op)
{
dentry->d_op = op;
+ /*
+ * The new ops may be NULL or may not implement everything that the
+ * old set (if any) did. We need to clear the flags just in case
+ * either of those is true.
+ */
+ dentry->d_flags &= ~(DCACHE_OP_HASH | DCACHE_OP_COMPARE |
+ DCACHE_OP_REVALIDATE | DCACHE_OP_REVALIDATE_RCU |
+ DCACHE_OP_DELETE);
if (!op)
return;
if (op->d_hash)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
