On Sun, 4 Jul 1999, Bill Sommerfeld wrote:

> So, I just fixed a long-standing bug where umount -f could cause a
> "dangling vnode" panic.
> 
> I think the change is pretty well documented by the change comment,
> but I'm sending a heads-up here just so people know..
> 
>     Fix kern/7906: race between unmount and getnewvnode()
> 
>     mp->mnt_flags & MNT_MWAIT is replaced by mp->mnt_wcnt, and a new mount
>     flag MNT_GONE is created (reusing the same bit).

As I asked on source changes, did you bump the kernel version letter? You
changed an internal kernel interface, after all. :-)

> One bit of (not new) ugliness I noticed is that getnewvnode() is
> called from {ffs,ext2fs,ufs}_vget() with ufs_hashlock held, which
> single-threads all vnode allocations.  Given how much work may need to
> be done in vinvalbuf() and vgonel() (vinvalbuf() does a VOP_FSYNC())
> this precludes a bunch of potential I/O parallelism when the system's
> dirtying a lot of vnodes (among other things, this probably also does
> evil things to LFS).

Would it work better to move to per-mount point hash tables? That way only
one mount point would get constapated at a time. Or do we need to get the
vnode and then lock the hash table?

Take care,

Bill