9-STABLE, ZFS, NFS, ggatec - suspected memory leak
rmacklem at uoguelph.ca
Thu Apr 26 11:53:51 UTC 2012
Oliver Brandmueller wrote:
> 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
> 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.
More information about the freebsd-stable