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
--- fs/nfsserver/nfs_nfsdport.c.sav 2012-04-25 16:50:05.000000000 -0400 +++ fs/nfsserver/nfs_nfsdport.c 2012-04-25 17:08:43.000000000 -0400 @@ -1047,6 +1047,8 @@ nfsvno_removesub(struct nameidata *ndp, else vput(ndp->ni_dvp); vput(vp); + if ((ndp->ni_cnd.cn_flags & SAVENAME) != 0) + nfsvno_relpathbuf(ndp); NFSEXITCODE(error); return (error); } @@ -1086,6 +1088,8 @@ out: else vput(ndp->ni_dvp); vput(vp); + if ((ndp->ni_cnd.cn_flags & SAVENAME) != 0) + nfsvno_relpathbuf(ndp); NFSEXITCODE(error); return (error); }
_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
