lockmgr panic on shutdown
Doug White
dwhite at gumbysoft.com
Sat Nov 1 18:13:02 PST 2003
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
> @@ -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.
>
>
--
Doug White | FreeBSD: The Power to Serve
dwhite at gumbysoft.com | www.FreeBSD.org
More information about the freebsd-current
mailing list