Date: Mon, 16 Oct 1995 11:44:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: current@freebsd.org Subject: Re: lstat flushes namei cache entry Message-ID: <199510161844.LAA25077@phaeton.artisoft.com> In-Reply-To: <199510161138.VAA24539@godzilla.zeta.org.au> from "Bruce Evans" at Oct 16, 95 09:38:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> lstat() has been inefficient since symlinks were POSIXified. > > Bruce > > *** vfs_lookup.c~ Fri Aug 25 16:05:33 1995 > --- vfs_lookup.c Mon Oct 16 21:06:30 1995 > *************** > *** 267,272 **** > wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); > docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; > if (cnp->cn_nameiop == DELETE || > ! (wantparent && cnp->cn_nameiop != CREATE)) > docache = 0; > rdonly = cnp->cn_flags & RDONLY; > --- 280,297 ---- > wantparent = cnp->cn_flags & (LOCKPARENT | WANTPARENT); > docache = (cnp->cn_flags & NOCACHE) ^ NOCACHE; > + /* > + * 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; > rdonly = cnp->cn_flags & RDONLY; 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> The *correct* set of fixes for this is moving the cache lookup into vfs_lookup.c instead of calling it per FS lookup mechanism. If I can't get a simple interface change into -current, it's unlikely that something that large in scope would go in (I would need to have the ability to disable it on a per FS type basis, etc.). Integrate my other changes first, and my patches to nameifree() and nfs_nameifree() to avoid duplicate free's, please. Then we can go off and consider moving the name cache. Also run the "find' I asked for for the cn_pnbuf references *after* the patches are applies so we can missed patches because of parallel development on things like procfs and devfs. Thanks, 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?199510161844.LAA25077>