ARM: Cortex-M: minor fix in the fault handling so some rare stack overflows are identified and are not reported as generic CPU errors. #31144
Conversation
|
@chrisc11 FYI, please take a look, if possible. |
ioannisg
force-pushed
the
arch_arm_cortex_m_fault_handle_stack_overflow_enhancement
branch
from
cf533a9 to
c770157
Compare
|
@galak @carlescufi pls take a quick look here |
There was a problem hiding this comment.
I think you could fold this into 236 and update mmfar with SCB->MMFAR there directly
There was a problem hiding this comment.
Well, for the reasons explained above, in the inline comment, I'd rather keep the design as is, because theoretically the MemManage handler could be preempted rigth after reading the MMARVALID flag, and there would be cases where the flag would not be valid any more.
By design in Zephyr the fault handlers have highest configurable priority, but i wanted to have a design that would be robust against changes :)
There was a problem hiding this comment.
hrm, yeah I guess one could have the MemManage exception at a lower priority than another ISR, get interrupted here, and fault from that ISR. That would be a tricky crash to investigate! :)
When the MMARVALID bit is not set, do not read the MMFAR register to get the fault address in a MemManage fault. This change prevents the fault handler to erroneously assume MMFAR contains a valid address. Signed-off-by: Ioannis Glaropoulos <[email protected]>
ioannisg
force-pushed
the
arch_arm_cortex_m_fault_handle_stack_overflow_enhancement
branch
from
c770157 to
7aca8ef
Compare
In rare cases when a thread may overflow its stack, the core will not report a Stacking Error. This is the case when a large stack array is created, making the PSP cross beyond the stack guard; in this case a MemManage fault won't cause a stacking error (but only a Data Access Violation error). We fix the fault handling logic so such errors are reported as stack overflows and not as generic CPU exceptions. Signed-off-by: Ioannis Glaropoulos <[email protected]>
ioannisg
force-pushed
the
arch_arm_cortex_m_fault_handle_stack_overflow_enhancement
branch
from
7aca8ef to
db4372d
Compare
4 participants
Two fixes here
Issue identified when working on #30028