Closed yashi closed 5 years ago
Good catch, once addressed we should transplant your example code to a test case to ensure this stays fixed.
CC @andyross
Definitely a bug. I don't think it was ever expected that a sched lock was a preemption point at all, that argument should be false. Alternatively, we should deprecate the API entirely -- it's not SMP-safe (that is, it prevents the current CPU from preempting your thread and can maybe be productively used for some purposes, but it's not a "lock" as it says nothing about what the other CPU is going to run).
Alternatively, we should deprecate the API entirely
Yeah I think people were using this mostly as an alternative to irq locking, I'd be OK with throwing a __deprecated tag on these, they should really use a semaphore or something in most cases
Describe the bug
k_sched_unlock()
callsupdate_cache()
withpreempt_ok
== 1. But whenk_sched_unlock()
is to unlock nested lock, it will preempt the current thread even though the caller still holds the scheduler lock.To Reproduce Steps to reproduce the behavior:
Expected behavior Nested lock should be taken care.
Impact A preemptive thread with the scheduler lock is unexpectedly preempted.
Screenshots or console output
Environment (please complete the following information): Doesn't matter.
Source code: