From owner-freebsd-fs@FreeBSD.ORG  Tue Mar 23 00:40:05 2010
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@hub.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B02B81065673
	for <freebsd-fs@hub.freebsd.org>; Tue, 23 Mar 2010 00:40:05 +0000 (UTC)
	(envelope-from gnats@FreeBSD.org)
Received: from freefall.freebsd.org (freefall.freebsd.org
	[IPv6:2001:4f8:fff6::28])
	by mx1.freebsd.org (Postfix) with ESMTP id 8501D8FC1B
	for <freebsd-fs@hub.freebsd.org>; Tue, 23 Mar 2010 00:40:05 +0000 (UTC)
Received: from freefall.freebsd.org (localhost [127.0.0.1])
	by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o2N0e5cf020841
	for <freebsd-fs@freefall.freebsd.org>; Tue, 23 Mar 2010 00:40:05 GMT
	(envelope-from gnats@freefall.freebsd.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o2N0e55M020836;
	Tue, 23 Mar 2010 00:40:05 GMT (envelope-from gnats)
Date: Tue, 23 Mar 2010 00:40:05 GMT
Message-Id: <201003230040.o2N0e55M020836@freefall.freebsd.org>
To: freebsd-fs@FreeBSD.org
From: Rick Macklem <rmacklem@uoguelph.ca>
Cc: 
Subject: Re: kern/144330: [nfs] mbuf leakage in nfsd with zfs 
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Rick Macklem <rmacklem@uoguelph.ca>
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2010 00:40:05 -0000

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