lockmgr panic on shutdown

[peter.edwards at openet-telecom.com]

>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
@@ -1158,7 +1158,7 @@
                        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.