On Fri, Oct 24, 2014 at 12:28:58AM +0900, OGAWA Hirofumi wrote:
> > What about this one?
>
> Looks like strange. If we want to tackle this at per-FS. We should not
> return double linked dir at first. Since double linked breaks dir
> hierarchy, even if this one can avoid that Oops, double linked can be
> easily the cause of another Oops, deadlock, etc.
>
> Well, this patch is untested though. For example, somethings like
> following. But, again, this fixes only one of cases in double linked.
> (And to fix fully, my mind was already talked.)
Hmm... Why hadn't d_splice_alias() caught that, though? Look: in that
case we see that inode is non-NULL, a directory and has an alias
(namely, dentry->d_parent). So we hit this:
new = __d_find_any_alias(inode);
if (new) {
if (!IS_ROOT(new)) {
spin_unlock(&inode->i_lock);
dput(new);
return ERR_PTR(-EIO);
}
if (d_ancestor(new, dentry)) {
spin_unlock(&inode->i_lock);
dput(new);
return ERR_PTR(-EIO);
}
and depending on whether that ->d_parent had been the filesystem root,
we hit either the former or the latter. IOW, we should've done
exactly that...
FWIW, there *is* a bug in that path - we ought to have done iput(inode)
on both failure exits in order to follow the calling conventions. But that
doesn't look like it would oops right there...
Could somebody repost the oops stack trace? The bug in d_splice_alias()
is real (and fairly old), but I'd like to understand if there's anything
else in the game...
--
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
