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

[Peter Holm]

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:
> 

I now have a scenario that fails, but not quite the same way you
describe.

It looks like this:

touch file1
echo xxx > file2
rename(file1, file2)

A different process performs stat() on both files in a tight loop.

Once in a while I observe that a stat() of file2, after the rename,
returns a link count of zero. Size is zero as expected, but the inode
number of file2 is unchanged.

I've been running the same test with your patch and not observed this
problem. This on UFS2 with SU enabled.

Regards,

- Peter