From 4ff60704a5f448507f6739f050fd8bdc64edb93a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= Date: Thu, 26 Sep 2024 13:11:39 -0700 Subject: [PATCH] kernel: mutex: Don't allow mutex_acquire with interrupts disabled Calling mutex_acquire with interrupts disabled is usually unsafe. Add a debug assert to catch this. Only check this after threading is enabled on the primary CPU though, as the thread that runs the initial init hooks run with interrupts disabled and in this case no other thread can own the mutex anyway. Also allow 0 timeout since vmm_get_address_description uses this to allow exception handlers to dump additional information when the vmm_lock is available. Bug: 304850822 Change-Id: I22c91c48b7853c0b8e0eb8da61cdfc9cd1650ae8 --- kernel/mutex.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/kernel/mutex.c b/kernel/mutex.c index d1e334ce..d7c59ac6 100644 --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -21,6 +21,19 @@ #include #include #include +#include + +static bool mutex_threading_ready; + +/* mutex_threading_ready is currently only used from a DEBUG_ASSERT */ +#if LK_DEBUGLEVEL > 1 + +static void mutex_threading_ready_init_func(uint level) { + mutex_threading_ready = true; +} + +LK_INIT_HOOK(mutex_threading_ready, mutex_threading_ready_init_func, LK_INIT_LEVEL_THREADING); +#endif /** * @brief Initialize a mutex_t @@ -69,6 +82,7 @@ status_t mutex_acquire_timeout(mutex_t *m, lk_time_t timeout) { panic("mutex_acquire_timeout: thread %p (%s) tried to acquire mutex %p it already owns.\n", get_current_thread(), get_current_thread()->name, m); #endif + DEBUG_ASSERT(!mutex_threading_ready || !timeout || !arch_ints_disabled()); THREAD_LOCK(state);