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