Bug 167266 - [zfs] [nfs] ZFS + new NFS export (sharenfs) leads to NAMEI leak
Summary: [zfs] [nfs] ZFS + new NFS export (sharenfs) leads to NAMEI leak
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-24 15:20 UTC by ob
Modified: 2012-05-29 14:57 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ob 2012-04-24 15:20:13 UTC
If you NFS export a ZFS, create/remove of a file or directory lead to the leak of a NAMEI path buffer on the NFS server.

This happens with new nfs (only NFSv3 tested) only, using the old NFS server does not trigger the NAMEI path buffer leak.

An exported UFS on the same machine/environment does not trigger the behaviour.

Fix: 

No fix known.
Workaround: using old NFS server.
How-To-Repeat: rc.conf:
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 64"
mountd_enable="YES"
mountd_flags="/etc/zfs/exports"
rpcbind_enable="YES"
lockd_enable="YES"

(mountd_flags not needed, if zfs_enable is set)


Assuming, you have a USB stick or similar as /dev/da0 (it will probably         
even work with an md device):                                                   
                                                                                
zpool create exptest /dev/da0                                                   
zfs sharenfs="-maproot=0 localhost" exptest                                     
# check with showmount -e exporting worked as expected                          
mount localhost:/exptest /mnt                                                   
cd /mnt                                                                         
vmstat -z | fgrep NAMEI                                                         
echo test > foo                                                                 
vmstat -z | fgrep NAMEI                                                         
rm foo                                                                          
vmstat -z | fgrep NAMEI                                                         

you may repeat the creation/removal of the file several time and you will notice the NAMEI count increasing by one on each delete operation, no matter if file or directory.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2012-04-25 06:01:00 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 dfilter service freebsd_committer freebsd_triage 2012-04-27 21:23:35 UTC
Author: rmacklem
Date: Fri Apr 27 20:23:24 2012
New Revision: 234740
URL: http://svn.freebsd.org/changeset/base/234740

Log:
  Fix a leak of namei lookup path buffers that occurs when a
  ZFS volume is exported via the new NFS server. The leak occurred
  because the new NFS server code didn't handle the case where
  a file system sets the SAVENAME flag in its VOP_LOOKUP() and
  ZFS does this for the DELETE case.
  
  Tested by:	Oliver Brandmueller (ob at gruft.de), hrs
  PR:		kern/167266
  MFC after:	1 month

Modified:
  head/sys/fs/nfsserver/nfs_nfsdport.c

Modified: head/sys/fs/nfsserver/nfs_nfsdport.c
==============================================================================
--- head/sys/fs/nfsserver/nfs_nfsdport.c	Fri Apr 27 20:16:20 2012	(r234739)
+++ head/sys/fs/nfsserver/nfs_nfsdport.c	Fri Apr 27 20:23:24 2012	(r234740)
@@ -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);
 }
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 3 Rick Macklem freebsd_committer freebsd_triage 2012-05-29 14:55:17 UTC
State Changed
From-To: open->closed


Fix is in head as r234740 and has been MFC'd to stable/9 
and stable/8 as r236134 and r236147 respectively.