From owner-freebsd-current Mon Sep 11 20:07:52 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA17896 for current-outgoing; Mon, 11 Sep 1995 20:07:52 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA17884 for ; Mon, 11 Sep 1995 20:07:49 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA14847 for current@freebsd.org; Mon, 11 Sep 1995 20:00:40 -0700 From: Terry Lambert Message-Id: <199509120300.UAA14847@phaeton.artisoft.com> Subject: Potentially serious NFS problem To: current@freebsd.org Date: Mon, 11 Sep 1995 20:00:40 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2319 Sender: current-owner@freebsd.org Precedence: bulk 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.