From owner-freebsd-current  Mon Oct 16 20:54:50 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id UAA08088
          for current-outgoing; Mon, 16 Oct 1995 20:54:50 -0700
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id UAA08081
          for <current@freebsd.org>; Mon, 16 Oct 1995 20:54:46 -0700
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA26625; Mon, 16 Oct 1995 20:49:32 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199510170349.UAA26625@phaeton.artisoft.com>
Subject: Re: lstat flushes namei cache entry
To: bde@zeta.org.au (Bruce Evans)
Date: Mon, 16 Oct 1995 20:49:32 -0700 (MST)
Cc: bde@zeta.org.au, terry@lambert.org, current@freebsd.org
In-Reply-To: <199510170234.MAA20172@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 12:34:16 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2220      
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;

[ ... my bad example ... ]

> 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().

rename, nfs_rename (both disallowed because the DELETE op).
lstat/olstat (both allowed because of the LOOKUP op).

Mount on nullfs, union, umapfs (all incorrectly enter because of the LOOKUP
op and the FOLLOW flag being set).


So I picked the wrong example.  8-).

I think there are several others because of LOCKPARENT setting wantparent
and the implied path save on CREATE/RENAME/MKDIR (see ufs/ufs/ufs_lookup.c).


My gut reaction is to remove the implied saves and make them explicit.
Then remove the LOCKPARENT from the WANTPARENT flag.  This would also
resolve the problem (I think).

The real problem is the level at which cache entries are made is incorrect.

The error case is unlikely in the extreme (considering no one uses the
FS's in question).  8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.