cvs commit: src/sys/ufs/ffs ffs_vnops.c

[Kostik Belousov]

On Fri, Mar 21, 2008 at 02:50:42PM +0200, Kostik Belousov wrote:
> On Fri, Mar 21, 2008 at 02:44:39AM -1000, Jeff Roberson wrote:
> > On Fri, 21 Mar 2008, Konstantin Belousov wrote:
> > 
> > >kib         2008-03-21 12:33:00 UTC
> > >
> > > FreeBSD src repository
> > >
> > > Modified files:
> > >   sys/ufs/ffs          ffs_vnops.c
> > > Log:
> > > Reduce the acquisition of the vnode interlock in the ffs_read() and
> > > ffs_extread() when setting the IN_ACCESS flag by checking whether the
> > > IN_ACCESS is already set. The possible race there is admissible.
> > 
> > I don't believe there is a race because we should always hold an exclusive 
> > vnode lock and the vnode interlock when clearing.  The exclusive node lock 
> We may hold only the shared vnode lock and the interlock when clearing,
> in the ufs_itimes().
Forgot to note that example of the ufs_itimes() call while holding only
the shared vnode lock is the ufs_getattr().

> 
> > would prevent ffs_read() from executing entirely, so we don't have to 
> > worry about races with clearing the bit.  Races to set the bit are handled 
> > by the vnode interlock.
> Yes, the race I meant is the clearing of the IN_ACCESS while performing
> unlocked read for check. It may be considered as a race, may be not.
> 
> > 
> > I should also mention that while this may seem innocuous enough this 
> > figured heavily in LOCK_PROFILING for a real workload.
> > 
> > Thanks,
> > Jeff
> > 
> > >
> > > Tested by:      pho
> > > Submitted by:   jeff
> > >
> > > Revision  Changes    Path
> > > 1.180     +4 -2      src/sys/ufs/ffs/ffs_vnops.c
> > >


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080321/e0ea00f4/attachment.pgp