Re: panic: lock (sleep mutex) vnode interlock not locked

On 10 Aug, Suleiman Souhlal wrote:
> Hello,
> 
> On Aug 10, 2005, at 1:55 AM, Alexander Kabaev wrote:
> 
>> On Tue, Aug 09, 2005 at 10:33:12PM +0200, Thierry Herbelot wrote:
>>
>>> Hello,
>>>
>>> I'm seeing the above panic on two machines (SMP BP6 and a  
>>> notebook) with
>>> recent -Current (certainly "heisenbug" : the same kernel runs  
>>> happily on the
>>> notebook).
>>> The panic log on the SMP machine follows.
>>>
>>>     TfH
>>>
>> <SKIP>
>>
>> Hi,
>>
>> could you try an patch below?
> 
> If you look at the place where the panic is happening, vlrureclaim(),  
> you'll notice that it shouldn't be possible for vgonel() to be called  
> on a doomed vnode. It seems, from KTR traces gotten by kris, that  
> there is a race between vlrureclaim() and vnlru_free() (called also  
> in getnewvnode()), but I've been unable to find it.


                if ((vp->v_iflag & VI_DOOMED) != 0 || vp->v_usecount ||
                    !LIST_EMPTY(&(vp)->v_cache_src) || (vp->v_object != NULL &&
                    vp->v_object->resident_page_count > trigger)) {
                        VI_UNLOCK(vp);
                        continue;
                }
                MNT_IUNLOCK(mp);
                vholdl(vp);
                if (VOP_LOCK(vp, LK_INTERLOCK|LK_EXCLUSIVE, td)) {
                        vdrop(vp);
                        MNT_ILOCK(mp);
                        continue;
                }
                VI_LOCK(vp);
                vgonel(vp);

What is preventing VI_DOOMED from being set while we're waiting for
VOP_LOCK()?  Contrary to what the VOP_LOCK(9) man page says about
LK_INTERLOCK, it looks like lockmgr() drops the vnode interlock before
it attempts to grab the vnode lock.