On Fri, Nov 29, 2013 at 11:44 AM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> So, should d870b4a191a3 be queued up for
> -stable releases to resolve this issue there as well, or am I
> misunderstanding your post above?
No, the bug d870b4a191a3 fixes is new to the 3.13 merge window (it's
due to the newly RCU'd vfsmounts).
But Al seems to have found another race that has been around for a
while. But that's a separate issue, and there's no patch for that yet
(and nobody has ever hit it, because we'd scream bloody murder if they
did).
Al - even in your scenario I don't see a NULL nd->inode, because when
we do an rmdir we remove the dentry, we don't turn it into a negative
one. Afaik, it would be a violation of all our dentry rules to change
the dentry->d_inode field while the dentry is live. The only way to
get a negative dentry (ie d_inode == NULL) should be from lookup (and
from a rename that switches the dentries around, but even then the
d_inode _stays_ NULL, it's just that we move the dentry itself
around).
That said, I do agree that the games we play with "nd->inode" are not
at all obvious. And I'm not actually convinced we need "nd->inode" AT
ALL these days. We used to have it for other reasons, but afaik these
days the only actual users are
- some sanity tests in the lookup code
- a few "inode_permission()" calls that I suspect could equally well
just use path.dentry->inode. Because either the dentry is stable, or
we're in RCU lookup and we'll revalidate it anyway.
Maybe I'm wrong. But iirc, the big reason for 'nd->inode' originally
was that it was the inode that was verified against the dentry
sequence number that we then passed on as a stable inode to the
low-level filesysystems. But that whole calling convention got cleaned
up with commits 12f8ad4b0533 and da53be12bbb4, and I really think most
of the historical reasons for having that nd->inode have gone away.
I dunno. I didn't check the three remaining "inode_permission()"
users, and maybe I missed some other use too. So maybe it's still
required, but my initial reaction when looking at it was "why do we
even have it any more"?
Linus
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
