Date: Wed, 24 Apr 2002 09:14:45 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: RE: mutex owned stuff fallible? Message-ID: <Pine.BSF.4.21.0204240912560.60421-100000@beppo> In-Reply-To: <XFMail.20020424101755.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Apr 2002, John Baldwin wrote:
>
> On 24-Apr-2002 Matthew Jacob wrote:
> >
> > This is a recent i386 SMP kernel:
> >
> >
> > panic: mutex isp not owned at ../../../kern/kern_synch.c:449
> > cpuid = 0; lapic.id = 00000000
> > Debugger("panic")
> > Stopped at Debugger+0x41: xorl %eax,%eax
> > db>
> > db> t
> > Debugger(c031189a) at Debugger+0x41
> > panic(c0310ae8,c030470d,c0312018,1c1,d2d08438) at panic+0xd8
> > _mtx_assert(d2d0843c,9,c0312018,1c1,69) at _mtx_assert+0x59
> > msleep(d2d08438,d2d0843c,4c,c0301260,7d0) at msleep+0x157
> > isp_mboxcmd(d2d08400,d2d19c04,f,d07dee8,0) at isp_mboxcmd+0x19c
> > isp_fw_state(d2d08400,d2d19c54,d2d08400,d2d09000,d2d08400) at
> > isp_fw_state+0x2b
> > isp_fclink_test(d2d08400,1e8480,d2d08400,d2d09000,d2d0843c) at
> > isp_fclink_test+0x5d
> > isp_control(d2d08400,4,d2d19d18) at isp_control+0x28b
> > isp_kthread(d2d08400,d2d19d48,d2d02a3c,c017b25c,0) at isp_kthread+0x6d
> > fork_exit(c017b25c,d2d08400,d2d19d48) at fork_exit+0x88
> > fork_trampoline() at fork_trampoline+0x37
>
> Is this code that is checked into the tree?
Yes.
> If so I can't see where
> isp_kthread() calls isp_control().
isp_fc_runstate is an inline that calls isp_control.
> mtx_owned() should always work. If
> we own the lock then we were the last to write to it, so the value in our
> cache can't be stale (at least, not the thread value, the contested bit
> could be set by another CPU, but we mask off that bit when reading the
> owner, so it's value doesn't matter). If we don't own the lock, it's
> value but we don't care so long as we don't get a false positive. Since
> we would have to write out the unowned cookie before another lock could
> grab it though, we would at least have a value that up to date, so we
> wouldn't read a stale value that had us owning the lock when we didn't.
This pp is hard to parse, but I think we're in agreement that this occurrence
is 'inconceivable'.
I am *very* puzzled.
>
> > Examination of the code path shows to me that this has been what it has been
> > for months- isp_lock is grabbed at the top of isp_kthread- various cv_wait &&
> > msleeps *should* assure it's still grabbed at the point in time it calls the
> > inline isp_fc_runstate which then calls isp_control...isp_mboxcmd...where
> > isp_mboxcmd calls msleep with isp_lock as the (should be still
> > owned) argument.
>
> What is the output of 'show locks' from ddb? (You need witness for it to work.)
Sigh. In order to be able to compile a kernel this year I turned off witness
:-(
>
> > WTF, O?
> >
> > -matt
>
> --
>
> John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
> "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0204240912560.60421-100000>