From owner-freebsd-fs@FreeBSD.ORG Fri Mar 5 07:45:48 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17C4B1065670; Fri, 5 Mar 2010 07:45:48 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id B4A5D8FC0A; Fri, 5 Mar 2010 07:45:47 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NnSEE-000BdD-7i; Fri, 05 Mar 2010 09:45:46 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Rick Macklem In-reply-to: References: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <4B89943C.70704@digiware.nl> <20100227220310.GA65110@icarus.home.lan> Comments: In-reply-to Rick Macklem message dated "Thu, 04 Mar 2010 19:14:15 -0500." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 05 Mar 2010 09:45:45 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, freebsd-fs@freebsd.org, Willem Jan Withagen , =?utf-8?B?RWlyaWsgw5h2ZXJieQ==?= , rwatson@freebsd.org, Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 07:45:48 -0000 > > > On Tue, 2 Mar 2010, Daniel Braniss wrote: > > > > > just keep sending insights/pointers and enjoy life > > > > > You could try this patch for sys/rpc/replay.c. Completely untested and > just typed into email (so don't give it to "patch", just edit the file). > > - try adding these 2 lines just before the end of replay_setreply() in > sys/rpc/replay.c: > > - } > + } else if (m) > + m_freem(m); > mtx_unlock(&rc->rc_lock); > } > > It's the only place I can see in replay.c that might leak, rick > this is what I did: --- a/sys/rpc/replay.c Mon Mar 01 18:29:54 2010 +0200 +++ b/sys/rpc/replay.c Fri Mar 05 09:24:17 2010 +0200 @@ -243,6 +243,9 @@ rce->rce_repbody = m; if (m) rc->rc_size += m_length(m, NULL); + } else if (m) { + printf("free m=%p ...\n", m); + m_freem(m); } mtx_unlock(&rc->rc_lock); } but it didn't help, it's not triggered Thanks for the explanation on the cache, things are begining to make sense. If I understand, the reason for this cache is to prevent re-applying an already performed rpc, which could lead to data corruption btw, the list of CCs is rather big, so if anyone feels he rather be removed, please let me know. cheers, danny