From owner-freebsd-current  Mon Oct 16 19:37:22 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id TAA04824
          for current-outgoing; Mon, 16 Oct 1995 19:37:22 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA04811
          for <current@freebsd.org>; Mon, 16 Oct 1995 19:37:16 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id MAA20172; Tue, 17 Oct 1995 12:34:16 +1000
Date: Tue, 17 Oct 1995 12:34:16 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199510170234.MAA20172@godzilla.zeta.org.au>
To: bde@zeta.org.au, terry@lambert.org
Subject: Re: lstat flushes namei cache entry
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
Precedence: bulk

>> + 	/*
>> + 	 * XXX the following seems to be just to recover from not setting
>> + 	 * NOCACHE for the DELETE cases (unlink, rmdir and the rename
>> + 	 * source).  In BSD4.4lite[2], docache was also cleared for the
>> + 	 * (wantparent && cnp->cn_nameiop == LOOKUP) case.  This case
>> + 	 * seems to only occur for lstat and olstat, when it is wrong
>> + 	 * to clear docache.  This case probably didn't occur before
>> + 	 * BSD4.4lite.  LOCKPARENT was introduced for lstat to support
>> + 	 * the new behaviour of symlinks (attributes inherited from the
>> + 	 * parent.
>> + 	 */
>>   	if (cnp->cn_nameiop == DELETE ||
>> ! 	    (wantparent && cnp->cn_nameiop != CREATE &&
>> ! 	     cnp->cn_nameiop != LOOKUP))
>>   		docache = 0;


>This will INCORRECTLY result in the contents of symlinks being seen as
>successfully looked up inferior components and entered into the cache.

>This is *BROKEN*.

>Consider:

>	cd /tmp
>	mkdir foo
>	cp /etc/ttys foo
>	mkdir fee
>	cd fee
>	ln -s /tmp/foo/ttys xxx
>	ls xxx
><xxx is found>
>	ls foo
><ttys is found because foo was incorrectly entered into the cache
> inferior to fee's vnode>

Actually, this prints `ls: foo: No such file or directory'.  This is not
surprising, since my change just (I hope) restores the caching behaviour
of BSD4.3.  As I tried to explain in the comment, BSD4.4 wants the
parent locked, and setting the LOCKPARENT flag fouled up the caching.
My change is only supposed to reenable the caching for lstat().  lstat()
is the only LOOKUP case where wantparent is nonzero (unless I've missed
a case).  Thus my change should be a no-op for everything except lstat().

Bruce