Date: Sat, 24 Jul 1999 09:38:47 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: mbuf leak found... for real this time. Message-ID: <199907241638.JAA35403@apollo.backplane.com> References: <199907240655.CAA05968@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:I found it... our favorite function... nfsrv_create()!!! :)
Yeee Haw!
:The problem was/is a create of an already existing file (with O_EXCL|O_CREATE,
:I would bet, but I don't have anyway to tell) returns *nothing* to the sender.
:The last time I had this problem it was because nfsrv_create() was not clearing
:error before its return (signalling to the caller that there was a more
:severe error and the packet should not be responded to. I have looked
:through the code, and arround line 1759 there should be a
:"goto nfsmreply0". Clearly we need to set error to 0 before we depart from
:this function with this kind of condition, I am just not sure the
:'correct' way to do it.
Hmmm. Interesting. An EEXIST error occuring at that point for an
NFSV3 mount will execute the correct nfsm_reply(), but since it is
NFSV3 the nfsm_reply() macro will not jump to a return(0) ... when
it finishes constructing the reply it falls through instead.
In this case I believe the nfsm_reply() call on line 1761 is correct,
but that we are failing to clear the error afterwords and this is
resulting in a non-zero return(). Thus the reply packet is being
properly formatted but not being transmitted.
I think all we need to do is set error = 0 for the NFSV3 case after
the nfsm_srvwcc_data() call. See the enclosed patch. We definitely
do not want to call nfsm_reply(0), because we already correctly call
nfsm_reply() on line 1761 (in STABLE).
I really appreciate the effort you've put into tracking down these
problems, Dave! You are virtually the only one who has enough of a
mix of NFS clients to truely test the server-side code. The only
testing I can do is between FreeBSD boxes!
In anycase, please try the enclosed patch. The patch, if correct,
should be applied to all branches.
And if there is anyone else up on NFS I would appreciate a review of
the patch! Remember that nfsm_reply() deals with errors differently
between NFSv2 and NFSv3.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Any-who, I am not able to reproduce this reliably since the OS (all OS's I
:have tried, including the troubled machine) issue a getattr() to see if the
:file exists as a first stage, not even attempting the create call for the
:first try. This looks like a race condition waiting for us to loose it.
:
:As another aside... I really do think that on returning with an error
:condition, it may be a good idea to free those mbuf/mbuf-clusters. I cannot
:see a reason to keep them lying arround.
:
:--
:David Cross | email: crossd@cs.rpi.edu
Index: nfs_serv.c
===================================================================
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.72.2.2
diff -u -r1.72.2.2 nfs_serv.c
--- nfs_serv.c 1999/06/30 22:05:14 1.72.2.2
+++ nfs_serv.c 1999/07/24 16:31:48
@@ -1765,6 +1765,7 @@
nfsm_srvpostop_attr(0, vap);
}
nfsm_srvwcc_data(dirfor_ret, &dirfor, diraft_ret, &diraft);
+ error = 0;
} else {
nfsm_srvfhtom(fhp, v3);
nfsm_build(fp, struct nfs_fattr *, NFSX_V2FATTR);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907241638.JAA35403>