[Bug 261198] bhyve host panics with: spin lock 0xffffffff81eac800 (callout) helpanic: spin lock held too long

From: <bugzilla-noreply_at_freebsd.org>
Date: Tue, 08 Feb 2022 02:23:55 UTC

--- 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. 
softclock_thread() locks the per-CPU callout lock and then acquires the current
thread's lock.

Usually the thread selected by sleepq_signal() will have its lock set to that
of the sleepqueue, and no deadlock is possible.  But if the thread is preparing
to go to sleep, its lock will still be a scheduler lock.  So it's not very easy
to hit this deadlock.

You are receiving this mail because:
You are the assignee for the bug.