cvs commit: src/sys/kern vfs_subr.c
Jeff Roberson
jroberson at chesapeake.net
Sun Oct 5 13:00:41 PDT 2003
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.
More information about the cvs-src
mailing list