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