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