> > > > i think that having some tricks in VOP_LOCK/UNLOCK/ISLOCKED is enough.
> > > > (in addition to stopping exporting v_vnlock, of course.)
> > > 
> > > What "tricks" could merge locks A and B into B?
> > 
> > something like this:
> > 	ffs_lock(...)
> > 	{
> > 
> > 		genfs_lock(vp, ...);
> > 		if (vp is snapshot) {
> > 			lockmgr(snaplk, ...);
> > 		}
> > 	}
> 
> This does't address the problem:
> 
>   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.
> 
>   If the "lockmgr(snaplk, ...);" has to wait -> deadlock.
> 
> -- 
> J,A|(Brgen Hannken-Illjes - hannken@netbsd.org

i don't see what's a problem.

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;

	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);

and finally, VOP_UNLOCK(vp, 0) (== ffs_unlock)
will unlock both of snaplk and vp->v_lock.
and then waiters will notice the transition and attempt to grab snaplk.

what am i missing?

YAMAMOTO Takashi