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