Date: Fri, 28 Apr 2006 16:00:30 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: freebsd-fs@freebsd.org Subject: vn_lock & ffs_snapremove Message-ID: <20060428130030.GC1270@deviant.kiev.zoral.com.ua>
next in thread | raw e-mail | index | archive | help
Look at the two code fragments
1. from vn_lock(9):
error = VOP_LOCK(vp, flags | LK_INTERLOCK, td);
flags &= ~LK_INTERLOCK;
KASSERT((flags & LK_RETRY) == 0 || error == 0,
("LK_RETRY set with incompatible flags %d\n", flags));
/*
* Callers specify LK_RETRY if they wish to get dead vnodes.
* If RETRY is not set, we return ENOENT instead.
*/
if (error == 0 && vp->v_iflag & VI_DOOMED &&
(flags & LK_RETRY) == 0) {
VOP_UNLOCK(vp, 0, td);
error = ENOENT;
break;
}
2. ffs_snapremove(9):
(vp->v_vnlock for snapshot vnode vp points to sn_snlock)
lkp = vp->v_vnlock;
vp->v_vnlock = &vp->v_lock;
Is there anything that would prevent these two fragments to intervene ?
Esp. bad looks the situation where VOP_LOCK() from vn_lock executed
and locked doomed snapshot vnode, after that ffs_snapremove replaces
vnode lock and VOP_UNLOCK attempted on _another_ lock.
If this scenario can happen (as it seems), then, probably,
some measures like transferlockers(9) are needed ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060428130030.GC1270>