From owner-freebsd-stable@FreeBSD.ORG Thu Apr 26 11:53:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EE72106566B; Thu, 26 Apr 2012 11:53:51 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id E27958FC08; Thu, 26 Apr 2012 11:53:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIw2mU+DaFvO/2dsb2JhbABEFoVSrGqCCQEBBAEjVhsOCgICDRkCWQaIGwULp1+TJIEvjh6BGASVfYERjy+DBA X-IronPort-AV: E=Sophos;i="4.75,486,1330923600"; d="scan'208";a="169602361" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 26 Apr 2012 07:53:48 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 2B93DB4063; Thu, 26 Apr 2012 07:53:48 -0400 (EDT) Date: Thu, 26 Apr 2012 07:53:48 -0400 (EDT) From: Rick Macklem To: Oliver Brandmueller Message-ID: <1695893954.3415457.1335441228131.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120426095454.GX65313@e-Gitt.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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 11:53:51 -0000 Oliver Brandmueller wrote: > 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? > Well, I think I can commit it to head with an MFC of 1 month. That way, hopefully you will have been able to test it in your production environment before it gets MFC'd to 9-STABLE. I suspect John's patch will be committed sometime later, but I'll leave that up to him. (He runs a server with ZFS, so he should be able to check for the leak.) > > Greeting and many thanks. > And thanks for tracking it down. It's surprising only one other person noticed this. I guess others don't have enough removes going on for the to get serious. rick