svn commit: r226967 - head/sys/ufs/ufs

Peter Holm peter at holm.cc
Fri Mar 2 00:00:33 UTC 2012


On Thu, Mar 01, 2012 at 04:47:41PM -0500, John Baldwin wrote:
> On Monday, October 31, 2011 11:01:47 am Peter Holm wrote:
> > Author: pho
> > Date: Mon Oct 31 15:01:47 2011
> > New Revision: 226967
> > URL: http://svn.freebsd.org/changeset/base/226967
> > 
> > Log:
> >   The kern_renameat() looks up the fvp using the DELETE flag, which causes
> >   the removal of the name cache entry for fvp.
> >   
> >   Reported by:	Anton Yuzhaninov <citrin citrin ru>
> >   In collaboration with:	kib
> >   MFC after:	1 week
> > 
> > Modified:
> >   head/sys/ufs/ufs/ufs_vnops.c
> 
> So I ran into this at work recently, and even this fix applied I was still 
> seeing rename()'s that were seemingly not taking effect.  After getting some 
> extra KTR traces, I figured out that the same purge needs to be applied to the 
> destination vnode.  Specifically, the issue I ran into was that was renaming 
> 'foo' to 'bar', but lookups for 'bar' were still returning the old file.  The 
> reason was that a lookup after the namei(RENAME) of the destination while 
> ufs_rename() had its locks dropped was readding the name cache entry for 
> 'bar', and then a cache_lookup() of 'bar' would return the old vnode as long 
> as that vnode was valid (e.g. if it had a link in another location, or other 
> processes had an open file descriptor for it).  I'm currently testing the 
> patch below:
> 

You wouldn't happen to have a small test scenario that demonstrates
this? I'm not able to reproduce the problem, based on your
description.
I'll try some more tomorrow.

- Peter


More information about the svn-src-head mailing list