Subject: Re: Redoing file system suspension API (update)
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
List: tech-kern
Date: 07/02/2006 22:33:19
On Sun, Jul 02, 2006 at 09:08:57PM +0900, YAMAMOTO Takashi wrote:
> > @@ -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?

The lockmgr man page states this as the right way to free memory
containing a lock.

> > +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?

At least on startup (cpu_initialize).

> why vn_ while it acts on struct mount?

Rename to vtrans_XXX and move to vfs_subr.c?

> 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.

At least the initial version will serialize suspensions (a lock in vfs_suspend).

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)