Date: Tue, 17 Oct 1995 12:34:16 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: current@freebsd.org Subject: Re: lstat flushes namei cache entry Message-ID: <199510170234.MAA20172@godzilla.zeta.org.au>
next 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; >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510170234.MAA20172>