8d13be016a
The irq_lock() API is a legacy API not to be used for synchronization
by new code, and in any case is only being used in cargo-cult fashion
here. These test cases all do synchronous exceptions, there's
literally nothing to synchronize against.
(And in this case they're exposing a legacy wart. On platforms where:
1. SMP=y, which causes irq_lock() to be implemented as a somewhat
complicated global lock
2. No ARCH_EXCEPT() macro is defined, which causes the kernel to
use a fallback that simply aborts the current thread.
...this test will then abort a thread holding the lock, which will
cause it to be orphaned (if it weren't a legacy API, the kernel
should probably attempt to clean it up in k_thread_abort(), but it
is, and it doesn't), so the next attempt to lock it will hang.
And it's even worse, because this test builds with SMP=y and
MP_NUM_CPUS=1, so the hand will happen with interrupts masked on a
system with only one CPU, and everything will lock up solid.)
Fixes #41877
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| CMakeLists.txt | ||
| prj_arm_fpu_sharing.conf | ||
| prj_armv8m_mpu_stack_guard.conf | ||
| prj.conf | ||
| protection_no_userspace.conf | ||
| README | ||
| sentinel.conf | ||
| testcase.yaml | ||
This test case verifies that kernel fatal error handling works correctly. If a thread causes a CPU exception, and it is not in an ISR or "essential" thread, the thread gets aborted and the rest of the system executes normally.