Subject: Re: Redoing file system suspension API (update)
To: None <hannken@eis.cs.tu-bs.de>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 07/05/2006 11:55:32
> > > @@ -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.

can there be lwps waiting for or holding this lock at this point?
iirc, LK_DRAIN is merely another kind of exclusive 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).

i couldn't find "cpu_initialize" other then sparc64 locore one.
is it what you meant?

YAMAMOTO Takashi