Date: Sat, 1 Nov 2003 18:17:02 -0800 (PST) From: Doug White <dwhite@gumbysoft.com> To: peter.edwards@openet-telecom.com Cc: current@freebsd.org Subject: RE: lockmgr panic on shutdown Message-ID: <20031101181623.O70057@carver.gumbysoft.com> In-Reply-To: <20031101181154.C70057@carver.gumbysoft.com> References: <3F6FE91100001039@mail.openet-telecom.com> <20031101181154.C70057@carver.gumbysoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Nov 2003, Doug White wrote:
> For giggles I'm rolling back vfs_default.c back to 1.87 since its along
> the backtrace path.
This didn't work so -CURRENT is fully broke.
I'd suggest staying on 10/30 not before 4PM PST if you want to not crash
on shutdown.
>
> 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@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@gumbysoft.com | www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031101181623.O70057>