core/mutex: use thread_yield_higher() in mutex_unlock() #20890
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
Using
sched_switch()
inmutex_unlock()
can result in crashes whenmutex_unlock()
is called from IRQ context. This however is a common pattern in RIOT to wake up a thread from IRQ. The reason for the crash is thatsched_switch()
assumesthread_get_active()
to always return a non-NULL
value. But when thread-less idle is used, no thread may be active after the last runnable thread exited. Usingthread_yield_higher()
instead solves the issue, asthread_yield_higher()
is safe to call from IRQ context without an active thread.Testing procedure
As described in #20812 (also add the
assert(active_thread != NULL);
tosched_switch()
to not rely on undefined behavior triggering the crash, but to crash reliably on invalid state).In addition to fixing the crash, it should not introduce regressions. I'm not sure how good the test coverage for mutex is, but at least the following passed:
for test in tests/core/mutex_*; do make BOARD=nucleo-f767zi -C $test flash test; done
Issues/PRs references
This fixes #20812
Alternative to #20878