DragonFly bugs List (threaded) for 2010-02
Re: panic: cleaned vnode isn't
Please try this 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
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.