Skip to content

async_context_threadsafe_background: fix incorrect mutex assertion in cross-core execute_sync() #2528

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Jun 19, 2025

Conversation

schkovich
Copy link

@schkovich schkovich commented Jun 16, 2025

In multicore configurations, async_context_threadsafe_background_execute_sync() contained an overly strict assertion used during cross-core calls:

hard_assert(!recursive_mutex_enter_count(&self->lock_mutex));

This check fails whenever the lock_mutex is held — regardless of who owns it — even in valid situations where the async core is processing background work.

The assertion does not check ownership, only that the enter_count is zero, which leads to false-positive failures on valid cross-core calls.

This patch replaces the enter-count check with a core-aware assertion:

hard_assert(self->lock_mutex.owner != calling_core);

This ensures the current core does not recursively hold the mutex, preventing deadlocks while allowing valid usage where the other core owns the lock.

The patch ensures that both get_core_num() and hard_assert() remain inlined as in the original implementation, preserving the performance characteristics under -Os and RelWithDebInfo builds.

Fixes #2527

… cross-core execute_sync()

In multicore configurations, `async_context_threadsafe_background_execute_sync()`
contained an overly strict assertion used during cross-core calls:

```c
hard_assert(!recursive_mutex_enter_count(&self->lock_mutex));
```

This check fails whenever the `lock_mutex` is held — regardless of *who*
owns it — even in valid situations where the async core is processing background
work.

The assertion does **not check ownership**, only that the `enter_count` is zero,
which leads to false-positive failures on valid cross-core calls.

This patch replaces the enter-count check with a core-aware assertion:

```c
hard_assert(self->lock_mutex.owner != calling_core);
```

This ensures the current core does not recursively hold the mutex, preventing
deadlocks while allowing valid usage where the *other* core owns the lock.

The patch ensures that both `get_core_num()` and `hard_assert()` remain inlined
as in the original implementation, preserving the performance characteristics
under `-Os` and `RelWithDebInfo` builds.

Fixes raspberrypi#2527

Signed-off-by: Goran Mišković <[email protected]>
@kilograham kilograham added this to the 2.1.2 milestone Jun 16, 2025
Use pre-existing mutex owner method; add a comment
@kilograham kilograham merged commit b1ca434 into raspberrypi:develop Jun 19, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants