Commit 4f9ace5
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 aa19686 commit 4f9ace5
1 file changed
+13
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
371 | 371 | | |
372 | 372 | | |
373 | 373 | | |
374 | | - | |
375 | | - | |
| 374 | + | |
| 375 | + | |
| 376 | + | |
| 377 | + | |
| 378 | + | |
| 379 | + | |
| 380 | + | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
376 | 387 | | |
377 | 388 | | |
378 | 389 | | |
| |||
0 commit comments