Why doesn’t the nesting depth of critical section take overflow into consideration?
In the RX600v2 porting, which is for Renesas RX family devices, implemantaiton of critical sections are used the functions in the kernel (vTaskEnterCritical and vTaskExitCritical) like this.
These functions increment/decrement the uxCriticalNesting member in a TCB to count the nesting depth of critical section. But they seem not to be take care of overflow of the uxCriticalNesting. For example, the following malicious application codes will cause nesting depth overflow, resulting in unintended critical section behavior:
typedef unsigned long UBaseType_t;
#define portCRITICAL_NESTING_IN_TCB ( 1 )
#define portENTER_CRITICAL() vTaskEnterCritical()
#define portEXIT_CRITICAL() vTaskExitCritical()
void Task ( void * pvParameters )
{
for( ; ; )
{
for ( unsigned long long i = 0; i < ( (unsigned long long) 0xFFFFFFFF + 1 ); i++ )
{
/* The nesting depth sets to 0 (overflow) in the last loop step. */
portENTER_CRITICAL();
Operation1();
}
Operation2();
for ( unsigned long long j = 0; j < ( (unsigned long long) 0xFFFFFFFF + 1 ); j++ )
{
/* The nesting depth fails decrement in the first loop step because current depth is 0 due to overflow. */
portEXIT_CRITICAL();
}
/* The nesting depth is not 0 at this point, so the critical section have not been exited yet. */
Operation3();
}
}
I understand that the above codes are unskillful use of critical sections, but it depends on the skill of users.
On the other hand, the functions vTaskSuspendAll and xTaskResumeAll have also the counter of nesting depth (uxSchedulerSuspended). These functions seem to be able to take care of overflow of the uxSchedulerSuspended due to the configASSERT, although this may not be the original intention.
So I’m wondering whether it’s necessary to take overflow into consideration in the first place, and why there is difference between uxCriticalNesting and uxSchedulerSuspended whether they consider overflow or not.