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

Rick Macklem rmacklem at uoguelph.ca
Wed Apr 25 21:34:13 UTC 2012


Oliver Brandmueller wrote:
> Hi,
> 
> After figuring an easy way to repeat the behaviour and hunting it down
> to the combination of ZFS+newNFS and removal of files or directories I
> opened PR kern/167266
> 
Good work isolating this!

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.

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.

rick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: namei-leak.patch
Type: text/x-patch
Size: 543 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120425/fadf56a1/namei-leak.bin


More information about the freebsd-stable mailing list