From nobody@FreeBSD.org  Tue Jan 29 21:42:41 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 682A116A468
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2008 21:42:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 5740113C457
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2008 21:42:41 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m0TLes6k083062
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 29 Jan 2008 21:40:54 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m0TLesbt083061;
	Tue, 29 Jan 2008 21:40:54 GMT
	(envelope-from nobody)
Message-Id: <200801292140.m0TLesbt083061@www.freebsd.org>
Date: Tue, 29 Jan 2008 21:40:54 GMT
From: Juli Mallett <juli@clockworksquid.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: __getcwd erroneously returning ENOENT
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         120128
>Category:       kern
>Synopsis:       [libc] [patch] __getcwd erroneously returning ENOENT
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    attilio
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 29 21:50:01 UTC 2008
>Closed-Date:    
>Last-Modified:  Sun Nov 22 13:50:00 UTC 2009
>Originator:     Juli Mallett
>Release:        8.0-CURRENT, kern.osreldate: 800008
>Organization:
>Environment:
FreeBSD alala.evergreen.edu 8.0-CURRENT FreeBSD 8.0-CURRENT #7: Tue Jan  8 16:03:13 PST 2008     root@alala.evergreen.edu:/usr/obj/usr/src/sys/ALALA  amd64

>Description:
When removing subdirectories, __getcwd is sometimes falsely returning
ENOENT, and continues to do so until pwd -L is invoked (it is the
stat($PWD) that fixes the problem, presumably this is updating some
cached information somewhere?) in a specific configuration (with a few
edge-cases).  This only occurs with tcsh for me, not sh, because the sh
builtin compensates for the problem.

^_^ (mallettj@alala:~)267% cd pwd
^_^ (mallettj@alala:~/pwd)268% mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo
pwd: .: Permission denied
^_^ (mallettj@alala:~/pwd)269% mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; pwd -L ; cd .. ; rm -rf foo
/home/mallettj/pwd/foo
^_^ (mallettj@alala:~/pwd)270% mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; ~/pwd/pwd -P ; cd .. ; rm -rf foo
/data/home/mallettj/pwd/foo
^_^ (mallettj@alala:~/pwd)271% ls -lartd .
drwxr-xr-x  3 mallettj  mallettj  512 Jan 29 15:38 .
^_^ (mallettj@alala:~/pwd)272% pwd -L
/home/mallettj/pwd
^_^ (mallettj@alala:~/pwd)273% pwd -P
/data/home/mallettj/pwd
^_^ (mallettj@alala:~/pwd)274% ls -lartd /data
drwxr-xr-x  8 root  wheel  512 Jul  5  2007 /data
^_^ (mallettj@alala:~/pwd)275% ls -lartd /data/home
drwx--x--x  9 root  wheel  512 Jan 23 19:00 /data/home
^_^ (mallettj@alala:~/pwd)276% ls -lartd /data/home/mallettj
drwxr-xr-x  13 mallettj  mallettj  1024 Jan 29 15:34 /data/home/mallettj
^_^ (mallettj@alala:~/pwd)277% ls -lartd /data/home/mallettj/pwd
drwxr-xr-x  3 mallettj  mallettj  512 Jan 29 15:38 /data/home/mallettj/pwd
^_^ (mallettj@alala:~/pwd)278% ls -lartd /home
lrwxr-xr-x  1 root  wheel  10 Jun 21  2007 /home -> /data/home
^_^ (mallettj@alala:~/pwd)279% cvs diff -u pwd.c
socket: Protocol not supported
Index: pwd.c
===================================================================
RCS file: /home/ncvs/src/bin/pwd/pwd.c,v
retrieving revision 1.25
diff -u -r1.25 pwd.c
--- pwd.c       9 Feb 2005 17:37:38 -0000       1.25
+++ pwd.c       29 Jan 2008 21:39:47 -0000
@@ -84,6 +84,8 @@
         * If we're trying to find the logical current directory and that
         * fails, behave as if -P was specified.
         */
+       struct stat phy;
+       stat(getenv("PWD"), &phy);
        if ((!physical && (p = getcwd_logical()) != NULL) ||
            (p = getcwd(NULL, 0)) != NULL)
                printf("%s\n", p);


>How-To-Repeat:
tcsh -c 'mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo'
>Fix:
Unlikely to have time to dig in to the kernel to figure out the root cause.
 Want to stress that the patch in the full description (obviously) is not
a solution, should someone stumble over this bug and think it is.  This
affects all callers of getcwd, including my shell:

^_^ (mallettj@alala:~/pwd)286% tcsh -c 'mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo'
tcsh: Permission denied
tcsh: Trying to start from "/home/mallettj"
pwd: .: Permission denied
^_^ (mallettj@alala:~/pwd)287% pwd -L
/home/mallettj/pwd
^_^ (mallettj@alala:~/pwd)288% tcsh -c 'mkdir foo ; cd foo ; mkdir bar ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo'
pwd: .: Permission denied



>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->attilio 
Responsible-Changed-By: jmallett 
Responsible-Changed-When: Sun Feb 3 12:53:33 PST 2008 
Responsible-Changed-Why:  
See if I can trick attilio into tracking this down further, since he's touched 
vfs_cache some recently. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=120128 

From: Jaakko Heinonen <jh@saunalahti.fi>
To: juli@clockworksquid.com
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning
	ENOENT
Date: Tue, 10 Feb 2009 18:55:17 +0200

 Hi,
 
 I couldn't reproduce this on 7.1-STABLE or 8.0-CURRENT (r188436). Do you
 still see this behavior?
 
 -- 
 Jaakko

From: Juli Mallett <juli@clockworksquid.com>
To: Jaakko Heinonen <jh@saunalahti.fi>
Cc: bug-followup@freebsd.org
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning ENOENT
Date: Tue, 10 Feb 2009 17:16:29 -0800

 On Tue, Feb 10, 2009 at 8:55 AM, Jaakko Heinonen <jh@saunalahti.fi> wrote:
 > I couldn't reproduce this on 7.1-STABLE or 8.0-CURRENT (r188436). Do you
 > still see this behavior?
 
 Yep.  Rebuilt userland and kernel today from SVN.
 
 ^_^ (mallettj@alala:~/tst2)8% tcsh -c 'mkdir foo ; cd foo ; mkdir bar
 ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo'
 pwd: .: Permission denied
 ^_^ (mallettj@alala:~/tst2)9% uname -a
 FreeBSD alala.evergreen.edu 8.0-CURRENT FreeBSD 8.0-CURRENT #3
 r188431: Tue Feb 10 11:50:37 PST 2009
 root@alala.evergreen.edu:/usr/obj/usr/src/sys/ALALA  amd64
 
 I believe it is specific to something in how the parent directories
 are laid out / their permissions.  Some relevant details:
 
 ^_^ (mallettj@alala:~)23% ls -ld /data /data/home /data/home/mallettj /home
 drwxr-xr-x  13 root      wheel      512 Jan 14 14:38 /data
 drwx--x--x  11 root      wheel      512 Dec 10 13:14 /data/home
 drwxr-xr-x  26 mallettj  mallettj  1536 Feb 10 17:11 /data/home/mallettj
 lrwxr-xr-x   1 root      wheel       10 Jun 21  2007 /home -> /data/home
 
 /dev/da0d on /data (ufs, local, soft-updates)
 
 Note that it doesn't happen in, i.e. my /tmp which is:
 drwxrwxrwt  17 root  wheel  13312 Feb 10 17:15 /tmp

From: Jaakko Heinonen <jh@saunalahti.fi>
To: Juli Mallett <juli@clockworksquid.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning
	ENOENT
Date: Wed, 11 Feb 2009 16:24:08 +0200

 On 2009-02-10, Juli Mallett wrote:
 > ^_^ (mallettj@alala:~/tst2)8% tcsh -c 'mkdir foo ; cd foo ; mkdir bar
 > ; rm -rf bar ; pwd -P ; cd .. ; rm -rf foo'
 > pwd: .: Permission denied
 
 > drwx--x--x  11 root      wheel      512 Dec 10 13:14 /data/home
 
 Thanks for the info. I think I know what's going on: UFS purges the
 parent directory from cache when you do rmdir(2) ("rm -rf bar" in your
 case). This causes __getcwd() to fail and getcwd(3) reverts to userspace
 traversal method which fails because of insufficient permissions to read
 /data/home directory.
 
 The behavior is allowed by SUSv3: "If a program is operating in a
 directory where some (grand)parent directory does not permit reading,
 getcwd() may fail, as in most implementations it must read the directory
 to determine the name of the file. This can occur if search, but not
 read, permission is granted in an intermediate directory, or if the
 program is placed in that directory by some more privileged process (for
 example, login)."
 
 Current __getcwd() implementation is not guaranteed to succeed.
 According to kib@ there is ongoing work to improve __getcwd(). See this
 message:
 
 http://lists.freebsd.org/pipermail/freebsd-fs/2009-February/005675.html
 
 -- 
 Jaakko

From: Mike Kelly <pioto@pioto.org>
To: bug-followup@freebsd.org, juli@clockworksquid.com
Cc:  
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning ENOENT
Date: Wed, 8 Apr 2009 10:30:23 -0400

 --000e0cd47b26b62de804670bf995
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 7bit
 
 Attached is a little C program that I've used to reproduce the problem
 on 7.1-RELEASE-p4.
 
 On Linux, this behaves as I would expect:
 
 $ ./getcwd_bug
 CWD: /home/pioto/top/mine
 CWD: /home/pioto/top/mine
 
 On FreeBSD, though:
 
  $ ./getcwd_bug
 CWD: /usr/home/pioto/top/mine
 getcwd: Permission denied
 
 -- 
 Mike Kelly
 
 --000e0cd47b26b62de804670bf995
 Content-Type: application/octet-stream; name="getcwd_bug.c"
 Content-Disposition: attachment; filename="getcwd_bug.c"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_fta41gnj0
 
 LyoKICogVGhpcyBpcyBhIHByb29mLW9mLWNvbmNlcHQgZm9yIGEgc3R1cGlkIEZyZWVCU0QgYnVn
 LgogKi8KCiNpbmNsdWRlIDxzdGRpby5oPgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDx1
 bmlzdGQuaD4KI2luY2x1ZGUgPHN5cy9zdGF0Lmg+CiNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KCmlu
 dAptYWluKGludCBhcmdjLCBjaGFyKiogYXJndikgewogICAgY2hhciBwYXRoW01BWFBBVEhMRU5d
 OwogICAgaWYgKC0xID09IG1rZGlyKCJ0b3AiLDA3NTUpKSB7CiAgICAgICAgcGVycm9yKCJta2Rp
 ciBcInRvcFwiIik7CiAgICAgICAgcmV0dXJuKDEpOwogICAgfQogICAgaWYgKC0xID09IG1rZGly
 KCJ0b3AvbWluZSIsMDc1NSkpIHsKICAgICAgICBwZXJyb3IoIm1rZGlyIFwidG9wL21pbmVcIiIp
 OwogICAgICAgIHJldHVybigxKTsKICAgIH0KICAgIGlmICgtMSA9PSBta2RpcigidG9wL21pbmUv
 dG1wIiwwNzU1KSkgewogICAgICAgIHBlcnJvcigibWtkaXIgXCJ0b3AvbWluZS90bXBcIiIpOwog
 ICAgICAgIHJldHVybigxKTsKICAgIH0KICAgIGlmICgtMSA9PSBjaG1vZCgidG9wIiwwMTExKSkg
 ewogICAgICAgIHBlcnJvcigiY2htb2QgXCJ0b3BcIiwgMDExMSIpOwogICAgICAgIHJldHVybigx
 KTsKICAgIH0KICAgIGlmICgtMSA9PSBjaGRpcigidG9wL21pbmUiKSkgewogICAgICAgIHBlcnJv
 cigiY2hkaXIgXCJ0b3AvbWluZVwiIik7CiAgICAgICAgcmV0dXJuKDEpOwogICAgfQogICAgaWYg
 KDAgPT0gZ2V0Y3dkKHBhdGgsTUFYUEFUSExFTikpIHsKICAgICAgICBwZXJyb3IoImdldGN3ZCIp
 OwogICAgICAgIHJldHVybigxKTsKICAgIH0KICAgIHByaW50ZigiQ1dEOiAlc1xuIixwYXRoKTsK
 ICAgIGlmICgtMSA9PSBybWRpcigidG1wIikpIHsKICAgICAgICBwZXJyb3IoInJtZGlyIFwidG1w
 XCIiKTsKICAgICAgICByZXR1cm4oMSk7CiAgICB9CiAgICBpZiAoMCA9PSBnZXRjd2QocGF0aCxN
 QVhQQVRITEVOKSkgewogICAgICAgIHBlcnJvcigiZ2V0Y3dkIik7CiAgICAgICAgcmV0dXJuKDEp
 OwogICAgfQogICAgcHJpbnRmKCJDV0Q6ICVzXG4iLHBhdGgpOwoKICAgIHJldHVybigwKTsKfQoK
 --000e0cd47b26b62de804670bf995--

From: Mike Kelly <pioto@pioto.org>
To: bug-followup@FreeBSD.org, juli@clockworksquid.com
Cc:  
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning
 ENOENT
Date: Thu, 9 Apr 2009 23:27:27 -0400

 --MP_/m3dGWPxY5Y/jwazzPn.V8GC
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline
 
 Sorry, I'm stupid, and it looks like I somehow attached the compiled
 program instead. Here's the real attachment.
 
 -- 
 Mike Kelly
 
 --MP_/m3dGWPxY5Y/jwazzPn.V8GC
 Content-Type: text/x-csrc
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment; filename=getcwd_bug.c
 
 /*
  * This is a proof-of-concept for a FreeBSD bug.
  */
 
 #include <stdio.h>
 #include <stdlib.h>
 #include <unistd.h>
 #include <sys/stat.h>
 #include <sys/param.h>
 
 int
 main(int argc, char** argv) {
     char path[MAXPATHLEN];
     if (-1 == mkdir("top",0755)) {
         perror("mkdir \"top\"");
         return(1);
     }
     if (-1 == mkdir("top/mine",0755)) {
         perror("mkdir \"top/mine\"");
         return(1);
     }
     if (-1 == mkdir("top/mine/tmp",0755)) {
         perror("mkdir \"top/mine/tmp\"");
         return(1);
     }
     if (-1 == chmod("top",0111)) {
         perror("chmod \"top\", 0111");
         return(1);
     }
     if (-1 == chdir("top/mine")) {
         perror("chdir \"top/mine\"");
         return(1);
     }
     if (0 == getcwd(path,MAXPATHLEN)) {
         perror("getcwd");
         return(1);
     }
     printf("CWD: %s\n",path);
     if (-1 == rmdir("tmp")) {
         perror("rmdir \"tmp\"");
         return(1);
     }
     if (0 == getcwd(path,MAXPATHLEN)) {
         perror("getcwd");
         return(1);
     }
     printf("CWD: %s\n",path);
 
     return(0);
 }
 
 
 --MP_/m3dGWPxY5Y/jwazzPn.V8GC--

From: Juli Mallett <juli@clockworksquid.com>
To: Mike Kelly <pioto@pioto.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning ENOENT
Date: Thu, 9 Apr 2009 20:30:56 -0700

 The first attachment came through fine, as did the second.
 
 It does not have the bug on Mac OS X, either, fwiw.

From: Damien Bobillot <damien.bobillot@m4x.org>
To: bug-followup@FreeBSD.org
Cc: Juli Mallett <juli@clockworksquid.com>,
 pdp@nl.demon.net,
 Robert Jan <rj@xs4all.nl>
Subject: Re: kern/120128: [libc] [patch] __getcwd erroneously returning ENOENT
Date: Sun, 22 Nov 2009 14:16:32 +0100

 It seems to be a duplicated with:
 - bin/121898: [nullfs] pwd(1)/getcwd(2) fails with Permission denied
 - kern/39527: getcwd() and unreadable parent directory
 - kern/22291: [nfs] getcwd(3) fails on recently-modified NFS-mounted  
 dirs
 
 I made my tests on 7.2-RELEASE-p2
 
 IN KERNEL
 =========
 
 The problem comes from the system call __getcwd() when used on some  
 specific FS (at least nullfs). This system call is defined in sys/kern/ 
 vfs_cache.c.
 
 It looks like cache_enter() is not called from the VOP "lookup" for  
 nullfs (null_lookup(), in sys/fs/nullfs/null_vnops.c). This is the  
 function that stores data later used by vn_fullpath1(), the function  
 doing the effective stuff for __getcwd().
 
 Not calling cache_enter() in the VOP "lookup" results in a ENOENT  
 error in vn_fullpath1(). The number of ENOENT errors is stored in the  
 sysctl entry "vfs.cache.numfullpathfail2".
 
 IN USERLAND
 ===========
 
 The getcwd() function (in libc, lib/libc/gen/getcwd.c) works in two  
 phases :
 - first try to use the system call __getcwd()
 - if it returns an error, falls back a userland algorithm, that opens  
 all parent directories. If the user don't have read right on at least  
 one parent directory, getcwd() returns with a EACCESS error.
 
 A simple workaround is to use a second fallback in getcwd(), in case  
 both phases fail : returning the content of the environment variable  
 PWD. (It'll then be possible to make getcwd() lie : potential security  
 issue ?)
 
 HOW TO REPEAT
 =============
 
 % mkdir -m 111 /aaa
 % mkdir /aaa/bbb
 % mount -t nullfs /lib /aaa/bbb
 % cd /aaa/bbb/geom
 % sysctl vfs.cache.numfullpathfail2
 vfs.cache.numfullpathfail2: 12498
 % su -fm nobody -c ktrace -f /tmp/ktrace.out /bin/pwd
 pwd: .: Permission denied
 % sysctl vfs.cache.numfullpathfail2
 vfs.cache.numfullpathfail2: 12499
 % kdump -f /tmp/ktrace.out | grep __getcwd
 99094 pwd      CALL  __getcwd(0x800902400,0x400)
 99094 pwd      RET   __getcwd -1 errno 2 No such file or directory
 
 
 grep -r cache_enter returns (in /usr/src/sys):
 ./fs/cd9660/cd9660_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./fs/cd9660/cd9660_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./fs/coda/coda_vnops.c:			cache_enter(dvp, *vpp, cnp);
 ./fs/coda/coda_vnops.c:		cache_enter(dvp, *vpp, cnp);
 ./fs/coda/coda_vnops.c:			cache_enter(dvp, *vpp, cnp);
 ./fs/coda/coda_vnops.c:			cache_enter(dvp, NULL, cnp);
 ./fs/coda/coda_vnops.c:			cache_enter(dvp, *vpp, cnp);
 ./fs/hpfs/hpfs_vnops.c:			cache_enter(dvp, *ap->a_vpp, cnp);
 ./fs/msdosfs/msdosfs_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./fs/msdosfs/msdosfs_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./fs/ntfs/ntfs_vnops.c:		cache_enter(dvp, *ap->a_vpp, cnp);
 ./fs/nwfs/nwfs_io.c:				cache_enter(vp, newvp, &cn);
 ./fs/nwfs/nwfs_vnops.c:			cache_enter(dvp, vp, cnp);
 ./fs/nwfs/nwfs_vnops.c:		cache_enter(dvp, *vpp, cnp);
 ./fs/pseudofs/pseudofs_vncache.c:				 * Some callers cache_enter(vp)  
 later, so
 ./fs/pseudofs/pseudofs_vnops.c:		cache_enter(vn, *vpp, cnp);
 ./fs/smbfs/smbfs_io.c:				cache_enter(vp, newvp, &cn);
 ./fs/smbfs/smbfs_vnops.c:		cache_enter(dvp, vp, cnp);
 ./fs/smbfs/smbfs_vnops.c:		cache_enter(dvp, *vpp, cnp);
 ./fs/tmpfs/tmpfs_vnops.c:		cache_enter(dvp, *vpp, cnp);
 ./fs/udf/udf_vnops.c:				cache_enter(dvp, *vpp, a->a_cnp);
 ./fs/udf/udf_vnops.c:			cache_enter(dvp, *vpp, a->a_cnp);
 ./fs/unionfs/union_vnops.c:			cache_enter(dvp, NULLVP, cnp);
 ./fs/unionfs/union_vnops.c:		cache_enter(dvp, vp, cnp);
 ./fs/unionfs/union_vnops.c:		cache_enter(dvp, NULLVP, cnp);
 ./gnu/fs/ext2fs/ext2_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./gnu/fs/ext2fs/ext2_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./gnu/fs/reiserfs/reiserfs_namei.c:		cache_enter(vdp, *vpp, cnp);
 ./gnu/fs/xfs/FreeBSD/xfs_vnops.c:			cache_enter(dvp, *vpp, cnp);
 ./gnu/fs/xfs/FreeBSD/xfs_vnops.c:		cache_enter(dvp, *vpp, cnp);
 ./kern/uipc_mqueue.c:			cache_enter(dvp, *vpp, cnp);
 ./kern/vfs_cache.c:cache_enter(dvp, vp, cnp)
 ./kern/vfs_cache.c:	CTR3(KTR_VFS, "cache_enter(%p, %p, %s)", dvp, vp,  
 cnp->cn_nameptr);
 ./nfs4client/nfs4_vnops.c:		cache_enter(dvp, newvp, cnp);
 ./nfs4client/nfs4_vnops.c:		cache_enter(dvp, newvp, cnp);
 ./nfs4client/nfs4_vnops.c:		cache_enter(dvp, newvp, cnp);
 ./nfsclient/nfs_vnops.c:		cache_enter(dvp, newvp, cnp);
 ./nfsclient/nfs_vnops.c:			cache_enter(dvp, newvp, cnp);
 ./nfsclient/nfs_vnops.c:			cache_enter(dvp, newvp, cnp);
 ./nfsclient/nfs_vnops.c:			        cache_enter(ndp->ni_dvp, ndp- 
  >ni_vp, cnp);
 ./sys/vnode.h:void	cache_enter(struct vnode *dvp, struct vnode *vp,
 ./ufs/ufs/ufs_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./ufs/ufs/ufs_lookup.c:		cache_enter(vdp, *vpp, cnp);
 ./cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:		 
 cache_enter(dvp, *vpp, cnp);
 ./cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:			 
 cache_enter(dvp, *vpp, cnp);
 
 So, it's effectively called from most FS implementations, excluding  
 nullfs.
 
>Unformatted:
