Date: Tue, 23 Mar 2010 00:40:05 GMT From: Rick Macklem <rmacklem@uoguelph.ca> To: freebsd-fs@FreeBSD.org Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs Message-ID: <201003230040.o2N0e55M020836@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/144330; it has been noted by GNATS.
From: Rick Macklem <rmacklem@uoguelph.ca>
To: Daniel Braniss <danny@cs.huji.ac.il>
Cc: Mikolaj Golub <to.my.trociny@gmail.com>,
Jeremy Chadwick <freebsd@jdc.parodius.com>, freebsd-fs@FreeBSD.org,
Kai Kockro <kkockro@web.de>, bug-followup@FreeBSD.org,
gerrit@pmp.uni-hannover.de
Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs
Date: Mon, 22 Mar 2010 20:48:50 -0400 (EDT)
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?201003230040.o2N0e55M020836>