bd077561d0
Our z_swap() API takes a key returned from arch_irq_lock() and releases it atomically with the context switch. Make sure that the action of the unlocking is to unmask interrupts globally. If interrupts would still be masked then that means there is an OUTER interrupt lock still held, and the code that locked it surely doesn't expect the thread to be suspended and interrupts unmasked while it's held! Unfortunately, this kind of mistake is very easy to make. We should catch that with a simple assertion. This is essentially a crude Zephyr equivalent of the extremely common "BUG: scheduling while atomic" error in Linux drivers (just google it). The one exception made is the circumstance where a thread has already aborted itself. At that stage, whatever upthread lock state might have existed will have already been messed up, so there's no value in our asserting here. We can't catch all bugs, and this can actually happen in error handling and/or test frameworks. Fixes #33319 Signed-off-by: Andy Ross <andrew.j.ross@intel.com> |
||
|---|---|---|
| .. | ||
| gen_offset.h | ||
| kernel_arch_interface.h | ||
| kernel_internal.h | ||
| kernel_offsets.h | ||
| kernel_tls.h | ||
| ksched.h | ||
| kswap.h | ||
| mmu.h | ||
| offsets_short.h | ||