Re: HAVE TRACE & DDB Re: FreeBSD 5.2-RC1 released

On Sat, 13 Dec 2003, Don Lewis wrote:

> On 13 Dec, Don Lewis wrote:
> > On 12 Dec, Jeff Roberson wrote:
> >
> >
> >> fsync: giving up on dirty: 0xc4e18000: tag devfs, type VCHR, usecount 44,
> >> writecount 0, refcount 14, flags (VI_XLOCK|VV_OBJBUF), lock type devfs: EXCL
> >> (count 1) by thread 0xc20ff500
> >
> > Why are we trying to reuse a vnode with a usecount of 44 and a refcount
> > of 14?  What is thread 0xc20ff500 doing?
>
> Following up to myself ...
>
> It looks like we're trying to recycle this vnode because of the
> following sysinstall code, in distExtractTarball():
>
>     if (is_base && RunningAsInit && !Fake) {
>         unmounted_dev = 1;
>         unmount("/dev", MNT_FORCE);
>     } else
>         unmounted_dev = 0;
>
> I'm guessing that the purpose of this code is to unmount devfs from /dev
> so that when the base distribution is unpacked it can populate /dev from
> the tarball.  This seems wrong, because it looks like the root file
> system is mounted on /mnt, and devfs is also mounted on /mnt/dev ...
>
> What happens if we forceably umount /dev while /dev/whatever holds a
> mounted file system?  It looks like this is handled by vgonechrl().  It
> looks to me like vclean() is going to do some scary stuff to this vnode.
>
> BTW, I think the root vnode is the root of the md file system, not the
> root of the file system being populated by sysinstall.  I don't know why
> there would be anything to sync at this point, though.
>
> I suspect that removing the above sysinstall code will fix the immediate
> problem, but there is still much I don't understand.
>

Excellent work!  I think I may know what's wrong.  If you look at rev
1.461 of vfs_subr.c I changed the semantics of cleaning a VCHR that was
being unmounted.  I now acquire the xlock around the operation.  This may
be the culprit.  I'm too tired to debug this right now, but I can look at
it in the am.

Thanks,
Jeff