Date: Mon, 22 Mar 2010 20:48:50 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: bug-followup@FreeBSD.org, freebsd-fs@FreeBSD.org, Kai Kockro <kkockro@web.de> Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs Message-ID: <Pine.GSO.4.63.1003222039480.27739@muncher.cs.uoguelph.ca> In-Reply-To: <E1NtjBJ-000AyL-B5@kabab.cs.huji.ac.il> References: <201003171120.o2HBK3CV082081@freefall.freebsd.org> <20100317113953.GA14582@icarus.home.lan> <Pine.GSO.4.63.1003171844120.20254@muncher.cs.uoguelph.ca> <86tys9eqo6.fsf@kopusha.onet> <Pine.GSO.4.63.1003212018180.28991@muncher.cs.uoguelph.ca> <E1NtfW6-0008E7-9q@kabab.cs.huji.ac.il> <Pine.GSO.4.63.1003220949490.11799@muncher.cs.uoguelph.ca> <E1NtjBJ-000AyL-B5@kabab.cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Mar 2010, Daniel Braniss wrote: [good stuff snipped] >> >> The initial leap doesn't worry me. That's just a design constraint. > yes, but new-nsfd does it better. > It's the classic tradeoff between a generic tool and one designed for a specific case. Because of quirks in NFSv4, the experimental server has no choice but to use a replay cache designed specifically for it and it knows assorted things about NFS. The one in sys/rpc/replay.c doesn't know anything about NFS, so it will be less efficient w.r.t. NFS. >> A slow leak after that is still a problem. (I might have seen the >> slow leak in testing here. I'll poke at it and see if I can reproduce >> that.) > > all I do is mount upd on a client and start a write process. > I only have a FreeBSD client at this point, and it doesn't cause the leak for nfsv3,udp for me here. Doug Rabson pointed out that there would be a leak for the "default:" case too, although didn't know if that would occur in practice. So, maybe you could test this variant of the patch (just in case that was the slow leak...): --- rpc/svc.c.sav 2010-03-21 18:46:20.000000000 -0400 +++ rpc/svc.c 2010-03-22 19:00:17.000000000 -0400 @@ -819,9 +819,11 @@ free(r->rq_addr, M_SONAME); r->rq_addr = NULL; } + m_freem(args); goto call_done; default: + m_freem(args); goto call_done; } } > there seems to be an NFSLOCK involved before calling replay_setsize ... > Ah, thanks for pointing that out. Thanks for the good testing. At least we're down to a slow leak..rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.1003222039480.27739>