Date: Sat, 24 Jul 1999 15:35:50 -0400 From: "David E. Cross" <crossd@cs.rpi.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: mbuf leak found... for real this time. Message-ID: <199907241935.PAA13884@cs.rpi.edu> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Sat, 24 Jul 1999 09:38:47 PDT." <199907241638.JAA35403@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907241935.PAA13884>