Date: Mon, 13 Jan 2025 14:01:11 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 283747] kernel panic after telegraf service restart Message-ID: <bug-283747-227-SOl9nBDzhl@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-283747-227@https.bugs.freebsd.org/bugzilla/> References: <bug-283747-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D283747 --- Comment #14 from Gleb Smirnoff <glebius@FreeBSD.org> --- Thanks, Eero! This gives a bit more of insight. So we see that the actual panic happens in kern_mutex.c:592: owner =3D lv_mtx_owner(v); if (TD_IS_RUNNING(owner)) { The TD_IS_RUNNING() dereferences td->td_state, which is exactly at 0x458 of= fset inside struct thread. So, lv_mtx_owner() gave us NULL on the previous line. But a few lines above we see that the lock value is not MTX_UNOWNED. This means that the value has one of the flags set: (MTX_RECURSED | MTX_CONTESTE= D | MTX_DESTROYED). Apparently it is MTX_DESTROYED, cause other flags are inte= ral to the mutex subsystem and having them on would mean there is a bug in mutex itself and we would see all different kinds of a panics. So, we got valid inpcb pointer with valid cred pointer, but the cred itself= has already went through crfree_final(). We got a step closer to understanding= the problem. Myself or Mark might come up with an idea, but getting more information would be very helpful. If you find a way to reproduce that, pl= ease let us know. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283747-227-SOl9nBDzhl>