Revert PR 1270: Direct access to current TCB inside stack macros

[aggarg]

Description

This reverts PR 1270. As concluded in the discussion here, if portSET_INTERRUPT_MASK and portCLEAR_INTERRUPT_MASK are implemented correctly to support recursive calls, this change is not needed.

Test Steps

NA.

Checklist:

• I have tested my changes. No regression in existing tests.
• [NA] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

NA.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AhmedIsmail02]

@aggarg Thank you for the changes, can you please fix the link-verifier CI check failure? I think it might be a transient error that might be fixed if restarted as they are all too-many-requests errors.

[raceant]

@aggarg As the issue #1270，the taskCHECK_FOR_STACK_OVERFLOW macro is invoked within the vTaskSwitchContext function, which itself may be called by the swi (software interrupt) handler. The call graph is as follows:

SWI_Handler ==> vTaskSwitchContext ==> taskCHECK_FOR_STACK_OVERFLOW  ==> pxCurrentTCB ==> portSET_INTERRUPT_MASK/portCLEAR_INTERRUPT_MASK 

FreeRTOS-Kernel/tasks.c

Line 5254 in fed39c5

taskCHECK_FOR_STACK_OVERFLOW();

Is the proper functioning of the aforementioned code dependent on portSET_INTERRUPT_MASK/portCLEAR_INTERRUPT_MASK have the same definition as portSET_INTERRUPT_MASK_FROM_ISR/portCLEAR_INTERRUPT_MASK_FROM_ISR ?

[aggarg]

Is the proper functioning of the aforementioned code dependent on portSET_INTERRUPT_MASK/portCLEAR_INTERRUPT_MASK have the same definition as portSET_INTERRUPT_MASK_FROM_ISR/portCLEAR_INTERRUPT_MASK_FROM_ISR ?

portSET_INTERRUPT_MASK_FROM_ISR/portCLEAR_INTERRUPT_MASK_FROM_ISR are only needed for nested interrupt. The context switch interrupt runs at the lowest priority and therefore, it should not be a problem.