9-STABLE, ZFS, NFS, ggatec - suspected memory leak

Oliver Brandmueller ob at e-Gitt.NET
Thu Apr 26 09:54:58 UTC 2012


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 at sysadm.in |
|                        Ich bin das Internet. Sowahr ich Gott helfe. |


More information about the freebsd-stable mailing list