RE: lockmgr panic on shutdown

For giggles I'm rolling back vfs_default.c back to 1.87 since its along
the backtrace path.

I suspect I'll need to back up the whole thing to before the commit for
the struct mount locking until jeff & kan can straighten things out.

On Sun, 2 Nov 2003 peter.edwards_at_openet-telecom.com wrote:

>
>
> >I can confirm the lockmgr panic on shutdown reported by someone else
> >earlier (whose message I mistakenly deleted).
> >
> >It looks like swapper is trying to undo a lock from pagedaemon and runs
> >into trouble. This is probably related to the Giant pushdown of
> >vm_pageout() that alc did last week.
> >
> >I'm building with INVARIANTS to see if that will catch more info.  Will
> >report back soon.
>
> Just happened me too. I think I see the problem:
>
> When boot() calls sync(), it passes &thread0 as the thread argument.
> This gets propgated up to ffs_sync, which:
>
>   calls vget(), which takes a thread argument.
>   does some stuff
>   calls vput(), which does _not_ take a thread argument
>
> The vget() is passed thread0, as passed from boot.
> The vput() gets the current thread, which is the process calling boot.
>
> The unlocking in vput is asserting that the same thread that aquired
> the lock is releasing it, which seems reasonable.
>
> The obvious solution might be to change line 1161 of ffs_vfsops to
> pass vget() "curthread" rather than td. I assume there's a good
> reason why "thread0" is passed from boot(), but I can't see why
> that's of any use to the vnode locking.
>
> i.e.:
> Index: ffs_vfsops.c
> ===================================================================
> RCS file: /usr/cvs/FreeBSD-CVS/src/sys/ufs/ffs/ffs_vfsops.c,v
> retrieving revision 1.221
> diff -u -r1.221 ffs_vfsops.c
> --- ffs_vfsops.c        1 Nov 2003 05:51:54 -0000       1.221
> +++ ffs_vfsops.c        2 Nov 2003 03:06:42 -0000
> _at__at_ -1158,7 +1158,7 _at__at_
>                         continue;
>                 }
>                 mtx_unlock(&mntvnode_mtx);
> -               if ((error = vget(vp, lockreq, td)) != 0) {
> +               if ((error = vget(vp, lockreq, curthread)) != 0) {
>                         mtx_lock(&mntvnode_mtx);
>                         if (error == ENOENT)
>                                 goto loop;
>
>
> How come tha parameters to vget and vput are lopsided like this?
>
> This might have something to do with the commit
> of revision 1.218 of ffs_vfsops.c, but I'm not sure.
>
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite_at_gumbysoft.com          |  www.FreeBSD.org