[EMAIL PROTECTED] wrote on Tue, 25 Mar 2008 15:10 -0500:
> In fact our error handling here looks to be a little wrong. When we return
> 0 from d_revalidate, the kernel assumes the file has been removed and
> populates the dcache with a negative dentry (then tries to create the file
> in the open case). But if getattr fails after lookup succeeds, we may have
> more than an invalid dentry.
>
> In most cases where getattr returns an error we probably want to push that
> error all the way back up the stack, instead of just populating the dcache
> with a negative dentry. We could check for ENOENT from getattr and return
> 0, otherwise return the errno? Do the same for lookup failure?
>
> Also, if the kernel gives us a null dentry, do we really want to return
> invalid dentry, or EINVAL with a big hairy gossip_err message to the log?
> At least in the current kernel, d_revalidate is never called with a null
> dentry.
I'm so far out of my element here. What you say makes a lot of
sense; however, we should hesitate to change anything in a big way,
given the 84 different versions of linux we support. Maybe a
testcase would help to motivate this sort of problem. Could be it
only occurs when multiple clients race on create/remove.
-- Pete
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
