From owner-freebsd-hackers Sat Jul 24 12:37:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 24B1B14BDD for ; Sat, 24 Jul 1999 12:37:35 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id PAA13884; Sat, 24 Jul 1999 15:35:50 -0400 (EDT) Message-Id: <199907241935.PAA13884@cs.rpi.edu> To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: mbuf leak found... for real this time. In-Reply-To: Message from Matthew Dillon of "Sat, 24 Jul 1999 09:38:47 PDT." <199907241638.JAA35403@apollo.backplane.com> Date: Sat, 24 Jul 1999 15:35:50 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. Yes, I concur with your patch whole-heartedly. Apparently last night I was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) I alas will not be able to test it. The machine is up and stable with 3k mbufs in reserve.. maybe later :) As an aside, what about getting rid of that mbuf leak if a nfs-service routine returns with error!=0? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message