Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Mar 2012 22:43:54 +0100
From:      Peter Holm <peter@holm.cc>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Rick Macklem <rmacklem@uoguelph.ca>, src-committers@freebsd.org
Subject:   Re: svn commit: r226967 - head/sys/ufs/ufs
Message-ID:  <20120305214354.GA41216@x2.osted.lan>
In-Reply-To: <201203051238.57501.jhb@freebsd.org>
References:  <201203021153.06614.jhb@freebsd.org> <1978600220.298005.1330754492306.JavaMail.root@erie.cs.uoguelph.ca> <20120303163843.GA72020@x2.osted.lan> <201203051238.57501.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 05, 2012 at 12:38:57PM -0500, John Baldwin wrote:
> On Saturday, March 03, 2012 11:38:43 am Peter Holm wrote:
> > On Sat, Mar 03, 2012 at 01:01:32AM -0500, Rick Macklem wrote:
> > > John Baldwin wrote:
> > > > On Friday, March 02, 2012 8:29:21 am Peter Holm wrote:
> > > > > 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.
> > > > 
> > > Peter, were you doing a stat() using the file name, or an fstat()?
> > > (Using stat() with afile name might explain it, maybe??)
> > > 
> > 
> > Yes. Switching to open()/fstat() of the "from" file in the loop, makes
> > the cache problem go away.
> 
> Using fstat avoids the changes of getting a stale name cache, so it just 
> avoids the race altogether.  However, there is no reason I can think of why 
> stat() should ever give you can inconsistent view of attributes.  You should 
> always get a consistent snapshot of attributes.
> 

Maybe my test scenario is broken, but it sure looks like the link
count is zero, after the rename.

$ ./r9.sh
FAIL: old and new "To" inode number is identical
stat() before the rename():
fromFile.log    : ino =    4, nlink = 1, size = 0
toFile.log.00065: ino =   70, nlink = 1, size = 8

stat() after the rename():
toFile.log.00065: ino =   70, nlink = 0, size = 0
$ 

This on r232558 with r232401 reverted. No problem on a pristine
HEAD of cause.

http://people.freebsd.org/~pho/r9.sh

- Peter



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120305214354.GA41216>