panic: lock (sleep mutex) vnode interlock not locked
Don Lewis
truckman at FreeBSD.org
Wed Aug 10 10:02:25 GMT 2005
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.
More information about the freebsd-current
mailing list