(1) Server has valid dentry and has bumped the use count so it can't
disappear locally. Client modifies packet to install a bogus dentry
pointer. Server calls d_validate, finds that the dentry doesn't exist
and returns error. But the dentry count has now leaked -- I don't see
how the server can do an eventual dput() to release the original dentry.
I tried very hard to make sure that dentry references were only held
during the actual handling of a specific transaction done by the
server, and that the dput() was done right before the reply packet
went onto the wire. I may have missed a few cases, but this was the
intent.
Also, there's a problem with the fh_copy routine, which can add a
reference to a dentry. (i.e. if dvalidate is set, doing a fh_copy adds
a reference to the dentry without doing a dget().)
Again, my intention was that if dvalidate is set, a real dput() must
have been done previously so that the blind counter increment is
indeed valid. Follow all the code paths, some of the stuff is hard to
catch. In particular I am talking about when the references get
finally dropped. Believe me when that isn't happening, all sorts of
fun stuff happens, which is why I am pretty confident I am taking care
of the counts properly in the current code.
For example, in many cases the code flow looks like:
nfs_proc_*() {
check_and_get_fh(); /* does dget() */
do_vfs_dot_c_op();
drop_dentry_ref(); /* does dput() */
}
Sometimes the control flow is not this simple, look at the RPC
procedure call table, in particular the final calls to
nfssvc_release_fhandle(). It took me some time to come to grips with
how that code path works, but in those cases that is when the dentry
ref gets dropped. More complications arise when multiple dentries
need to be held to complete a single operation.
Please show me specific code paths where the dentry ref count does not
get dropped after a nfsd transaction is done. Then we can talk more
specifically about whatever problems you think are there. Right now
what you are saying tells me "dentry counts don't get taken care of
across transactions", but _where_ in particular is this happening?
Later,
David "Sparc" Miller
davem@caip.rutgers.edu