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/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283747 --- 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 = lv_mtx_owner(v); if (TD_IS_RUNNING(owner)) { The TD_IS_RUNNING() dereferences td->td_state, which is exactly at 0x458 offset 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_CONTESTED | MTX_DESTROYED). Apparently it is MTX_DESTROYED, cause other flags are interal 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, please let us know. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-283747-227-SOl9nBDzhl>