Fix log mutex initialization TOCTOU race condition

[map588]

Two threads calling cbm_ui_log_append() simultaneously before the mutex was initialized could both pass the atomic_load check and double-initialize the mutex.

Replace with atomic CAS (0→1→2 state machine) so exactly one thread initializes.

[Copilot]

Pull request overview

Fixes a TOCTOU race during lazy initialization of the log ring-buffer mutex when multiple threads call cbm_ui_log_append() concurrently at startup.

Changes:

• Introduces log_mutex_ensure_init() using an atomic CAS-based 0→1→2 initialization state machine.
• Updates cbm_ui_log_append() and handle_logs() to call the new ensure-init helper before taking the log mutex.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

After initialization (state==2), this still executes an atomic compare-exchange on every log append / log fetch. Consider adding a fast path (e.g., load state first and return immediately when it's already fully initialized) so the steady-state cost is just a single atomic load.

Suggested change

	/* CAS from 0 → 1: exactly one thread initializes the mutex */
	int expected = 0;
	if (atomic_compare_exchange_strong(&g_log_mutex_init, &expected, 1)) {
	cbm_mutex_init(&g_log_mutex);
	atomic_store(&g_log_mutex_init, 2); /* 2 = fully initialized */
	} else {
	/* Another thread is initializing — spin until done */
	while (atomic_load(&g_log_mutex_init) != 2) {
	/* tight spin is fine — init takes nanoseconds */
	}
	}
	/* Fast path: already fully initialized? Just return. */
	int state = atomic_load(&g_log_mutex_init);
	if (state == 2) {
	return;
	}
	/* CAS from 0 → 1: exactly one thread initializes the mutex */
	if (state == 0) {
	int expected = 0;
	if (atomic_compare_exchange_strong(&g_log_mutex_init, &expected, 1)) {
	cbm_mutex_init(&g_log_mutex);
	atomic_store(&g_log_mutex_init, 2); /* 2 = fully initialized */
	return;
	}
	}
	/* Another thread is initializing — spin until done */
	while (atomic_load(&g_log_mutex_init) != 2) {
	/* tight spin is fine — init takes nanoseconds */
	}

[Copilot]

The wait loop is a tight spin with no backoff/yield; if mutex init ever takes longer than expected (e.g., OS contention, debug builds), this can burn CPU. Consider adding a small pause/backoff (e.g., cbm_usleep(0/1) or cbm_nanosleep) inside the loop, and updating the comment that assumes init always takes “nanoseconds”.

Suggested change

	/* Another thread is initializing — spin until done */
	while (atomic_load(&g_log_mutex_init) != 2) {
	/* tight spin is fine — init takes nanoseconds */
	/* Another thread is initializing — wait until done (avoid tight spinning) */
	while (atomic_load(&g_log_mutex_init) != 2) {
	/* Small sleep/backoff to avoid burning CPU if init is slower than expected */
	cbm_usleep(1);

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.