Date: Mon, 11 Sep 1995 20:00:40 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: current@freebsd.org Subject: Potentially serious NFS problem Message-ID: <199509120300.UAA14847@phaeton.artisoft.com>
next in thread | raw e-mail | index | archive | help
Doug, are you there? 8-).
I have detected a problem in the NFS server code, though at present I am
not certain whether it will manifest as a memory leak or as a double
freeing of cn_pnbuf's (which depends on what's meant by VOP_ABORTOP()
when called in nfs/nfs_serv.c).
I found this when tracking the path name buffer allocation/deallocation
layering violations in the standard FS code.
What is happening is that there are instances where an allocated path
name buffer (cn_pnbuf) is being "discarded" inconsistantly.
In nfsrv_create() it is being explicitly FREE'ed after a call to
VOP_CREATE() has failed. It is *never* freed, explicitly or by
VOP_ABORTOP() side effect, in the success case.
In the case of a truncate, it is being free'ed and a call is issued to
VOP_ABORTOP() (which in the current code, will also free it).
This type of thing occurs in numerous places.
It's almost as if the programmer were half-aware that a side effect of
a VOP_LOOKUP with a cn_nameiop of CREATE or RENAME implies a SAVENAME
in the underlying file systems?
I'm not prepared to crack this nut all by myself at present, especially
with active work in the NFS code taking place.
My current changes to all other file systems are to remove the implied
freeing of the cn_pnbuf by all VOP_ABORTOP() routines in all other
file systems and the implied freeing of cn_pnbuf in the VOP_ routines
that expect to be called with (cn_flags & HASBUF) true.
--
My suggested changes for the NFS code would be to make all buffer
frees explicit by a call to a routine called nfs_nameifree() to be
located in nfs/nfs_subs.c:
nfs_nameifree( ndp)
register struct nameidata *ndp;
{
struct componentname *cnp = &ndp->ni_cnd;
if( cnp->cn_flags & HASBUF)
FREE(cnp->cn_pnbuf, M_NAMEI);
}
And assume the underlying file system does *NOT* free the buffer on *any*
VOP_ calls whatsoever. This would fit with my current patches, but would
result in needing a combined code integration (I'm willing to work on
that too, despite the getpage/putpage changes throwing all my diffs off).
I have client side patches for nfs_node.c and nfs_vnops.c (of course).
This is strictly an NFS server code problem.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509120300.UAA14847>