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)