Al Viro wrote on Sat, Aug 01, 2015: > And that has turned the check done to an inode that *was* ours at some > point (i.e. fetching it had been followed by checking that ->d_seq had > been still valid) into something completely unprotected. Suppose we > are in lazy mode and somebody had evicted nd->path.dentry after we'd looked > it up and before that check. Sure, its ->d_seq had been bumped by that, > and we would've failed anyway. With ECHILD. Which, unlike ENOTDIR, is > "repeat in non-lazy mode". That sounds like a good find, I was looking at how to claim/protect the entry somehow as well but I just have no idea... > Folks, could you check if this fixes the problems you are seeing? > > diff --git a/fs/namei.c b/fs/namei.c > index ae4e4c1..b16c3a7 100644 > --- a/fs/namei.c > +++ b/fs/namei.c > @@ -1954,7 +1954,11 @@ OK: > continue; > } > } > - if (unlikely(!d_can_lookup(nd->path.dentry))) > + if (unlikely(!d_can_lookup(nd->path.dentry))) { > + if (nd->flags & LOOKUP_RCU) { > + if (unlazy_walk(nd, NULL, 0)) > + return -ECHILD; > + } > return -ENOTDIR; > } > } Unfortunately, still happens for me. I had to adapt a bit because using an old kernel (4bf46a272), will try again with a recent master to doublecheck, but I had a break on the "if (nd->flags & LOOKUP_RCU)" check: - sometimes fails without ever hitting the check. I think this fixes the "ENOTDIR" I had described, but there's at least another way to fail? - When we do hit it, we're into LOOKUP_RCU at this point alright, unlazy_walk fails and we try again without RCU -- can confirm the recovery process goes OK (well, that it went OK at least once) Thanks, -- Dominique -- 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