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/ [email protected] | | Ich bin das Internet. Sowahr ich Gott helfe. | _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
