Skip site navigation (1)Skip section navigation (2)
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>