-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests: SMP: Two threads synchronize failed using mutex or semaphore while both doing irq_lock() #33551
Comments
@LeiW000 FYI, please. |
This was in fact a design bug in the older kernel (and the nanokernel before it), where it was "legal" (but never really "correct") to sleep with an irq lock held, for the simple reason that it wasn't possible for the kernel to detect and enforce it. We don't allow this anymore, because spinlocks are non-recursive (though there's a separate bug tracking the fact that we should detect and assert on this, which we don't). But the legacy irq_lock() API is sort of a gray area as to what is legal. You can't sleep with a lock. Don't do that. |
Thank you so much for clarify this, @andyross . I saw issue #33319 you filed earlier, and I think I will remove the test case which tries to do sleep while irq locked. Maybe it could become a negative test case after the assertion being added. So, do mutex and semaphore also can not be used in this way, too? |
Mutexes and semaphores are blocking constructs already. Sleeping with one held (strictly: a semaphore can't be "owned", but you can use it like a lock if it has only one token) is a well-defined operation and does exactly what you would expect. The problem with sleeping with an irq lock held is that it "release" the lock, but that's not true for IPC primitives. So that is legal. It's also a very, very, very bad idea. But application bugs and misfeatures aren't the kernel's job to enforce. Closing this one, as I think the question has been answered. |
Ok, I think this can be closed. Thanks for your explanation! |
Describe the bug
Given two threads synchronize by using mutex or semaphore, under they both lock interrupt by irq_lock(), it would hang up when the second thread call k_mutex_lock() or k_sem_take().
Please see the new added test case in PR #31010
,which are test_smp_irq_lock_sem() and test_smp_irq_lock_sem().
We know zehpyr has such a mechanism:
while call irq_lock(), interrupts remain disabled only while the thread is running. If the thread performs an operation that allows another thread to run (for example, giving a semaphore or sleeping for N milliseconds), the interrupt lock no longer applies, and
interrupts may be re-enabled while other processing occurs.
We were not sure if this is normal behavior or a correct user case, so please help to clarify this.
To Reproduce
Steps to reproduce the behavior:
or twister -T tests/kernel/smp (failed on qemu_x86_64, qemu_x86_64_kpti, qemu_cortex_a53_smp)
Expected behavior
test cases test_smp_irq_lock_sem() and test_smp_irq_lock_sem() pass as expected.
Impact
If there are user scenarios like this, two threads both lock interrupt and they sync synchronize by using mutex or semaphore, would hang up.
Logs and console output
Environment (please complete the following information):
Additional context
This is an unmerged test case.
The text was updated successfully, but these errors were encountered: