tests/kernel/fatal/exception/sentinel test is failing for various nrf platforms

[ioannisg]

Describe the bug
tests/kernel/fatal/exception/ stack_sentinel test variant is failing for various nRF platforms
tested on nRF5340 and nRF9160.

To Reproduce

On current master:
Build flash and run stack sentinel test variant of tests/kernel/fatal/exception

Expected behavior
Test should not assert.

Impact
kernel test failing

Logs and console output

ASSERTION FAIL [chan && chan < (0 + 1)] @ WEST_TOPDIR/zephyr/drivers/timer/nrf_rtc_timer.c:214
E: r0/a1:  0x00000004  r1/a2:  0x000000d6  r2/a3:  0x00000000
E: r3/a4:  0x00006f31 r12/ip:  0x00000000 r14/lr:  0x00001e77
E:  xpsr:  0x49000025
E: Faulting instruction address (r15/pc): 0x00006436
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Fault during interrupt handling
E: Current thread: 0x200002e8 (main)
Caught system error -- reason 4
Was not expecting a crash

[ioannisg]

@nordic-krch I suspect a driver issue here, but might be wrong.

[ioannisg]

SImilar as reported in #30526

[jcyrax]

This is a bug due to adjusting stack start and size for threads using floating point after sentinel is written to stack. This results in sentinel at wrong location and so it fails on first test.

You can see that in kernel/thread.c setup_thread_stack() sentinel is written to address stack_buf_start = Z_THREAD_STACK_BUFFER(stack); and right after that in arch_new_thread() arch/arm/core/aarch32/thread.c stack start is adjusted due to larger guard area used with floating points, but sentinel is never written to this location.

#if FP_GUARD_EXTRA_SIZE > 0
	if ((thread->base.user_options & K_FP_REGS) != 0) {
		/* Larger guard needed due to lazy stacking of FP regs may
		 * overshoot the guard area without writing anything. We
		 * carve it out of the stack buffer as-needed instead of
		 * unconditionally reserving it.
		 */
		thread->stack_info.start += FP_GUARD_EXTRA_SIZE;
		thread->stack_info.size -= FP_GUARD_EXTRA_SIZE;
	}
#endif /* FP_GUARD_EXTRA_SIZE */

[ioannisg]

Cannot reproduce this any more. Tried nrf52, nrf53, nrf91, with or without FPU. Closing this.
@PerMac if the test fails for nRF platforms, pls, re-open, with Medium priority.

[ioannisg]

This is a bug due to adjusting stack start and size for threads using floating point after sentinel is written to stack. This results in sentinel at wrong location and so it fails on first test.

You can see that in kernel/thread.c setup_thread_stack() sentinel is written to address stack_buf_start = Z_THREAD_STACK_BUFFER(stack); and right after that in arch_new_thread() arch/arm/core/aarch32/thread.c stack start is adjusted due to larger guard area used with floating points, but sentinel is never written to this location.

#if FP_GUARD_EXTRA_SIZE > 0
	if ((thread->base.user_options & K_FP_REGS) != 0) {
		/* Larger guard needed due to lazy stacking of FP regs may
		 * overshoot the guard area without writing anything. We
		 * carve it out of the stack buffer as-needed instead of
		 * unconditionally reserving it.
		 */
		thread->stack_info.start += FP_GUARD_EXTRA_SIZE;
		thread->stack_info.size -= FP_GUARD_EXTRA_SIZE;
	}
#endif /* FP_GUARD_EXTRA_SIZE */

Sentinel should not be used together with MPU stack guards, so there's no stack adjustment of stack_info.start that applies here, as far as I understand.

[PerMac]

@ioannisg I haven't seen it for a while. I think it was the same root cause as in #30526 and was fixed by #30487.