cvs commit: src/sys/kern vfs_subr.c

[Jeff Roberson]

On Sun, 5 Oct 2003, Don Lewis wrote:

> On  5 Oct, Jeff Roberson wrote:
> > On Sun, 5 Oct 2003, Don Lewis wrote:
> >
> >> On  5 Oct, Jeff Roberson wrote:
> >> > jeff        2003/10/05 00:12:38 PDT
> >> >
> >> >   FreeBSD src repository
> >> >
> >> >   Modified files:
> >> >     sys/kern             vfs_subr.c
> >> >   Log:
> >> >    - Fix an XXX.  Check the error of vn_lock() in vflush().  Don't specify
> >> >      LK_RETRY either, we don't want this vnode if it turns into another.
> >> >    - Remove the code that checks the mount point after acquiring the lock
> >> >      we are guaranteed to either fail or get the vnode that we wanted.
> >> >
> >> >   Revision  Changes    Path
> >> >   1.465     +2 -13     src/sys/kern/vfs_subr.c
> >>
> >> What keeps this from spinning if some other thread holds the lock on the
> >> first vnode on the list?
> >>
> >
> > It should only fail if the vnode was vcleaned() out from under us, right?
> > If that's the case than the list has been modified by the time we relock
> > it and check.
> >
> > Do you agree
>
> What about the !FORCECLOSE case where the vnode is locked by some other
> thread that is doing I/O on it?  The call to vn_lock() will fail, we'll
> re-lock mntvnode_mtx, start the loop again, and immediately try to lock
> the same vnode again.
>
> It looks to me like we either need to sleep and wait for the vnode lock,
> or we need to skip to the next vnode and try this vnode again later.
>

In vflush we do sleep on the vnode lock.  The flags are LK_EXCLUSIVE |
LK_INTERLOCK.  We dont pass in LK_NOWAIT.