From owner-freebsd-stable@FreeBSD.ORG Thu Apr 26 09:54:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 98982106564A; Thu, 26 Apr 2012 09:54:58 +0000 (UTC) (envelope-from prvs=0463424ae3=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 22CB98FC0A; Thu, 26 Apr 2012 09:54:58 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SNLPa-000Dy7-NF; Thu, 26 Apr 2012 11:54:54 +0200 Date: Thu, 26 Apr 2012 11:54:54 +0200 From: Oliver Brandmueller To: Rick Macklem Message-ID: <20120426095454.GX65313@e-Gitt.NET> Mail-Followup-To: Rick Macklem , freebsd-stable@freebsd.org, John References: <20120424142751.GV65313@e-Gitt.NET> <1587904922.3402243.1335389645650.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1587904922.3402243.1335389645650.JavaMail.root@erie.cs.uoguelph.ca> X-Face: "TT~P'b_)-jKU_0^a=usXryz`YTz)z.[FZrI,A~PREI2U}frrZ`>_J&; ^t|^.dR/mqtC,Vb.Y>~u8(|aL)vAv(k">zY"]*m*y|b8S7:WK[/qP5i>HO#Ek; C[X:b|FP0*Ly_4Ni User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Oliver Brandmueller Cc: freebsd-stable@freebsd.org Subject: Re: 9-STABLE, ZFS, NFS, ggatec - suspected memory leak X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:54:58 -0000 Hi, On Wed, Apr 25, 2012 at 05:34:05PM -0400, Rick Macklem wrote: > Good work isolating this! Thank you! > I now see the problem. The new NFS server code assumed that VOP_LOOKUP() > calls would not set SAVENAME, so it expected the path buffer to be free'd > by the nfsvno_namei() when it hadn't set SAVENAME. > > It turns out ZFS sets SAVENAME in zfs_lookup() for the DELETE case. > > The attached patch, which is also here, should fix the problem for now: > http://people.freebsd.org/~namei-leak.patch > > Please test this patch and let me know if it fixes the leak. Thanx for the explanation - anf coming up with a patch that fast! I applied the patch and in my testing environment I don't see the leak anymore. I will not be able to apply it to our prod environment before about mid of May, since I don't want to leave my fellow co-workers with any problems while being on holidays :) > jwd@ is working on a patch that will avoid using uma_zalloc() to get > a path buffer for most cases for performance reasons. Once that patch > goes it, the code should be patched so that it checks for SAVENAME being > set for all cases where uma_zalloc() has allocated a path buffer, so that > no more leaks like this will happen when underlying file systems set > SAVENAME. So is itlikely, that this final version will at some time be included into 9-STABLE or will the current patch (given more positive results come up) make it into -STABLE until the other one is ready? Greeting and many thanks, Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. |