qemu-cr16/stubs/iothread-lock.c
Peter Xu c89d1c879a bql: Fix bql_locked status with condvar APIs
QEMU has a per-thread "bql_locked" variable stored in TLS section, showing
whether the current thread is holding the BQL lock.

It's a pretty handy variable.  Function-wise, QEMU have codes trying to
conditionally take bql, relying on the var reflecting the locking status
(e.g. BQL_LOCK_GUARD), or in a GDB debugging session, we could also look at
the variable (in reality, co_tls_bql_locked), to see which thread is
currently holding the bql.

When using that as a debugging facility, sometimes we can observe multiple
threads holding bql at the same time. It's because QEMU's condvar APIs
bypassed the bql_*() API, hence they do not update bql_locked even if they
have released the mutex while waiting.

It can cause confusion if one does "thread apply all p co_tls_bql_locked"
and see multiple threads reporting true.

Fix this by moving the bql status updates into the mutex debug hooks.  Now
the variable should always reflect the reality.

Signed-off-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20250904223158.1276992-1-peterx@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2025-11-03 11:59:32 +01:00

45 lines
727 B
C

#include "qemu/osdep.h"
#include "qemu/main-loop.h"
static bool bql_is_locked = false;
static uint32_t bql_unlock_blocked;
bool bql_locked(void)
{
return bql_is_locked;
}
void rust_bql_mock_lock(void)
{
bql_is_locked = true;
}
void bql_lock_impl(const char *file, int line)
{
}
void bql_unlock(void)
{
assert(!bql_unlock_blocked);
}
void bql_block_unlock(bool increase)
{
uint32_t new_value;
assert(bql_locked());
/* check for overflow! */
new_value = bql_unlock_blocked + increase - !increase;
assert((new_value > bql_unlock_blocked) == increase);
bql_unlock_blocked = new_value;
}
bool mutex_is_bql(QemuMutex *mutex)
{
return false;
}
void bql_update_status(bool locked)
{
}