> @@ -616,8 +617,9 @@ dounmount(struct mount *mp, int flags, s
>  	if (LIST_FIRST(&mp->mnt_vnodelist) != NULL)
>  		panic("unmount: dangling vnode");
>  	mp->mnt_iflag |= IMNT_GONE;
>  	lockmgr(&mp->mnt_lock, LK_RELEASE | LK_INTERLOCK, &mountlist_slock);
> +	lockmgr(&mp->mnt_trans_lock, LK_DRAIN, NULL);

is this LK_DRAIN necessary?

> +int
> +vn_trans_lock(struct mount *mp, int flags)
> +{
> +	int error, pflags;
> +	struct vn_trans_entry *vte, *new_vte;
> +
> +	KASSERT((flags & ~(LK_SHARED|LK_EXCLUSIVE|LK_NOWAIT)) == 0);
> +
> +	if (mp == NULL)
> +		return 0;

when mp can be NULL?

why vn_ while it acts on struct mount?

btw, what's a plan about mmap'ed vnodes?
- while uvm_fault in your original patch seems to prevent
  faults on a mmap'ed vnode, it seems to do nothing to already mapped pages.
- as far as you take vn_trans_lock in fault handler,
  read/write on mmap'ed address can takes vn_trans_lock on
  multiple filesystems.  i think it can deadlock unless you make sure that
  more than one instance of suspension (write-lock) can't happen on a system
  at once.

YAMAMOTO Takashi