Date: Sun, 5 Oct 2003 16:00:37 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Don Lewis <truckman@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern vfs_subr.c Message-ID: <20031005155831.K99666-100000@mail.chesapeake.net> In-Reply-To: <200310051013.h95ADqN1049043@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031005155831.K99666-100000>