Date: Tue, 08 Feb 2022 02:23:55 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 261198] bhyve host panics with: spin lock 0xffffffff81eac800 (callout) helpanic: spin lock held too long Message-ID: <bug-261198-27103-IpYSagWnnE@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261198-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-261198-27103@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=3D261198 --- Comment #6 from Mark Johnston <markj@FreeBSD.org> --- Looks like there is a lock order reversal: sleepq_signal() selects a thread= on the sleepqueue, locks it, and then sleepq_remove_thread() stops the td_slpcallout callout, which requires a per-CPU callout lock.=20 softclock_thread() locks the per-CPU callout lock and then acquires the cur= rent thread's lock. Usually the thread selected by sleepq_signal() will have its lock set to th= at of the sleepqueue, and no deadlock is possible. But if the thread is prepa= ring to go to sleep, its lock will still be a scheduler lock. So it's not very = easy to hit this deadlock. --=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-261198-27103-IpYSagWnnE>