fh_verify (in fs/nfsd/nfsfh.c) uses dentry->inode and its contents (eg., i_size) without ever calling the fileysstem revalidate op. The result is bad (out-of-date) stat information). Puting the following code into fh_verify avoids this: inode = dentry->d_inode; /* Before using this inode, it must be revalidated with the filesystem. */ if (inode->i_op && inode->i_op->revalidate) { error = inode->i_op->revalidate(dentry); if (error) goto out; }
Changing product to Red Hat Linux beta
This defect is considered MUST-FIX for Winston Gold-release
I might be wrong, but isn't that a bug that has been hanging around for ages? If i remember correctly the effect of this bug is that sometimes after saving a file on a server you have to wait a couple of seconds before these updates are reflected on the client. Here a small example: You are working on a package, edit a file directly on a server and recompile it over NFS. If you start the make very quickly after the save often the saved file was not recompiled! So this really should be done. I'm looking into the fix if it is doing the right thing(tm) and doesn't break anything else.
Hmmm. After testing it it doesn't show up that way anymore. It still might be a good idea to include this patch in the kernel as this would ensure the revalidation of the inode. It is being used at various other places in the filesystem tree, so i guess we can safely assume that it will work :) Can someone put this patch into the kernel source: --- linux/fs/nfsd/nfsfh.c.orig Fri Aug 18 12:32:30 2000 +++ linux/fs/nfsd/nfsfh.c Fri Aug 18 12:32:47 2000 @@ -1195,6 +1195,16 @@ check_type: dentry = fhp->fh_dentry; inode = dentry->d_inode; + + /* Before using this inode, it must be revalidated with the + filesystem. + */ + if (inode->i_op && inode->i_op->revalidate) { + error = inode->i_op->revalidate(dentry); + if (error) + goto out; + } + error = nfserr_stale; /* On a heavily loaded SMP machine, more than one identical requests may run at the same time on different processors.
Michael, please take a look at this one. Doug is ignoring us.
We can't evaluate this change in time, I'm deferring it.
Alan, could you please comment on this one?
NFS is not cache coherent. So it was never truely a bug. Its just an undesirable. 2.2.18 NFS changes should have killed this one off