On Tue, Jun 22, 2004 at 01:32:55AM +0900, YAMAMOTO Takashi wrote:
> > > > > i think that having some tricks in VOP_LOCK/UNLOCK/ISLOCKED is en=
ough.
> > > > > (in addition to stopping exporting v_vnlock, of course.)
> > > >=20
> > > > What "tricks" could merge locks A and B into B?
> > >=20
> > > something like this:
> > > 	ffs_lock(...)
> > > 	{
> > >=20
> > > 		genfs_lock(vp, ...);
> > > 		if (vp is snapshot) {
> > > 			lockmgr(snaplk, ...);
> > > 		}
> > > 	}
> >=20
> > This does't address the problem:
> >=20
> >   During snapshot construction there is a point where we need to go
> >   from "normal" vnode lock to "snapshot" vnode lock. Here the vnode is
> >   (and must remain) locked and may have waiters. To make the situation
> >   worse, the file system is currently suspended.
> >=20
> >   If the "lockmgr(snaplk, ...);" has to wait -> deadlock.
> >=20
> > --=20
> > J=1B,A|=1B(Brgen Hannken-Illjes - hannken@netbsd.org
>=20
> i don't see what's a problem.
>=20
> given the ffs_lock() above, snapshot code can go from
> normal to snapshot vnode lock by:
> 	vn_lock(vp, LK_INTERLOCK | LK_EXCLUSIVE | LK_RETRY);
> 	lockmgr(snaplk, ...);
> 	mark vp as snapshot;
>=20
> 	instead of:
> 	vn_lock(vp, LK_INTERLOCK | LK_EXCLUSIVE | LK_RETRY);
> 	transferlockers(&vp->v_lock, vp->v_vnlock);
> 	lockmgr(&vp->v_lock, LK_RELEASE, NULL);
>=20
> and finally, VOP_UNLOCK(vp, 0) (=3D=3D ffs_unlock)
> will unlock both of snaplk and vp->v_lock.
> and then waiters will notice the transition and attempt to grab snaplk.
>=20
> what am i missing?

You mean (because vp is already locked and the vn_lock() will fail):

	lockmgr(snaplk, ...);
	mark vp as snapshot;

Yes, this looks equivalent. But it still costs an extra function call on
every vn_lock() (ffs_lock->genfs_lock instead of genfs_lock) and
VOP_UNLOCK() while transferlockers() only costs an extra test
"if (lkp->lk_newlock !=3D NULL)".
--=20
J=FCrgen Hannken-Illjes - hannken@netbsd.org