Skip to content

Commit fb44805

Browse files
committed
tests/arm_interrupt: Disable persistent lock test when USE_SWITCH=y
I'm at a loss here. The feature this test case wants to see (on ARMv7M, not ARMv6M) is the ability to take a irq_lock() inside a system call and then see that future system calls from the same thread continue to hold the lock. That's not documented AFAICT. It's also just a terrible idea because either: 1. The obvious denial of service implications if user code is allowed to run in an unpreemptible mode, or: 2. The broken locking promise if this is implemented to release the lock and reacquire it in an attempt to avoid #1. (FWIW: my read of the code is that #1 is the current implementation. But hilariously the test isn't able to tell the difference!) And in any case it's not how any of our other platforms work (or can work, in some cases), making this a non-portable system call API/feature at best. Leave it in place for now out of conservatism, but disable with the new arch_switch() code, whose behavior matches that of other Zephyr userspaces. Signed-off-by: Andy Ross <[email protected]>
1 parent 0c52668 commit fb44805

File tree

1 file changed

+13
-2
lines changed

1 file changed

+13
-2
lines changed

tests/arch/arm/arm_interrupt/src/arm_interrupt.c

Lines changed: 13 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -371,8 +371,19 @@ void z_impl_test_arm_user_interrupt_syscall(void)
371371
#if defined(CONFIG_ARMV6_M_ARMV8_M_BASELINE)
372372
/* Confirm IRQs are not locked */
373373
zassert_false(__get_PRIMASK(), "PRIMASK is set\n");
374-
#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE)
375-
374+
#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE) && defined(CONFIG_USE_SWITCH)
375+
/* Confirm IRQs are not locked */
376+
zassert_false(__get_BASEPRI(), "BASEPRI is set\n");
377+
#elif defined(CONFIG_ARMV7_M_ARMV8_M_MAINLINE) && !defined(CONFIG_USE_SWITCH)
378+
/* The original ARMv7M userspace implementation had the
379+
* somewhat odd (and dangerous!) behavior that an interrupt
380+
* mask done in a system call would persist (!!) on return
381+
* into userspace, and be seen again once we were back in
382+
* kernel mode, and this is a test for it. It's legacy
383+
* though, not something we ever documented, and not the way
384+
* userspace works (or even can work!) on other platforms, nor
385+
* with the newer arch_switch() code. Consider removing.
386+
*/
376387
static bool first_call = 1;
377388

378389
if (first_call == 1) {

0 commit comments

Comments
 (0)