Re: panic: cleaned vnode isn't

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Please try this patch:

	fetch http://apollo.backplane.com/DFlyMisc/lock01.patch

    I don't know if this will fix it or not.  There is an issue in
    allocfreevnode() where a vnode whos v_lock.lk_flags sets
    LK_CANRECURSE can be improperly reallocated while in the middle
    of being freed, but only if the filesystem's VOP_RECLAIM code
    recurses.

    The problem is that really only UFS sets this flag, and UFS doesn't
    recurse inside its VOP_RECLAIM code.  HAMMER, on the otherhand,
    does not use this flag but it CAN recurse inside VOP_RECLAIM.

    So the only way I can think of for this crash to occur is if UFS
    recurses in softupdates and allocates new vnodes while reclaiming
    a vnode, the allocate code then reusing a HAMMER vnode and reclaiming
    IT, and HAMMER then recursing and trying to allocate a new vnode
    itself and winding up reusing the vnode UFS was originally trying to
    reclaim.  A difficult path to say the least.

    Both your crash dump and the one I got from leaf today crashed on
    a HAMMER vnode being reallocated with a seemingly impossible state.
    Clearly a MP race, but I couldn't find a smoking gun related to
    HAMMER itself.  Basically vp->v_mount was NULL, the vnode was in
    a reclaimed state, but vp->v_data was still pointing at the
    HAMMER inode and the HAMMER inode was still pointing back at the
    vp.  That implies the vnode was reallocated back to the same
    HAMMER inode recursively from within the VOP_RECLAIM itself,
    which shouldn't be possible.

    So, lets see if this patch fixes it or not.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>