Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Oct 1995 20:49:32 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        bde@zeta.org.au (Bruce Evans)
Cc:        bde@zeta.org.au, terry@lambert.org, current@freebsd.org
Subject:   Re: lstat flushes namei cache entry
Message-ID:  <199510170349.UAA26625@phaeton.artisoft.com>
In-Reply-To: <199510170234.MAA20172@godzilla.zeta.org.au> from "Bruce Evans" at Oct 17, 95 12:34:16 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >> + 	/*
> >> + 	 * 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510170349.UAA26625>