Fix vTaskSuspendAll assertion for critical nesting count #1029
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.
Description
The macro
portGET_CRITICAL_NESTING_COUNT
is implemented like the following:It involves the following 2 steps:
portGET_CORE_ID()
.pxCurrentTCBs
and correspondingpxCurrentTCB
.If a context switch happens between step 1 and step 2, the core ID may be changed as the task may be scheduled on a different core. In that case, we would end up accessing the wrong TCB and thereby, wrong critical nesting count.
This PR address the issue by ensuring that
portGET_CRITICAL_NESTING_COUNT
is called with interrupts disabled to ensure atomicity.Test Steps
Before this PR
There will be assertion in
vTaskSuspendAll()
if running this XMOS demo.Checklist:
The following unit test is fixed in FreeRTOS/FreeRTOS#1204
Related Issue
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.