Date: Tue, 08 Feb 2022 02:23:55 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261198 --- 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.