From owner-freebsd-current Tue Sep 12 02:52:12 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA01057 for current-outgoing; Tue, 12 Sep 1995 02:52:12 -0700 Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id CAA01044 for ; Tue, 12 Sep 1995 02:52:07 -0700 Received: (from dfr@localhost) by minnow.render.com (8.6.9/8.6.9) id KAA02553; Tue, 12 Sep 1995 10:54:50 +0100 Date: Tue, 12 Sep 1995 10:54:48 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: current@freebsd.org Subject: Re: Potentially serious NFS problem In-Reply-To: <199509120300.UAA14847@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: current-owner@freebsd.org Precedence: bulk On Mon, 11 Sep 1995, Terry Lambert wrote: > Doug, are you there? 8-). Still here :-) > 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'm not prepared to crack this nut all by myself at present, especially > with active work in the NFS code taking place. I am not currently working on the nfs code. I think that John is working on the client code but not the server. Feel free to make changes to the server side. > > 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). This definately sounds like the right thing to do. Go for it! > > I have client side patches for nfs_node.c and nfs_vnops.c (of course). > This is strictly an NFS server code problem. Agreed. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939