7dee7a6139
There was a brief (but seen in practice on real apps on real hardware!) race with the switch-based z_swap() implementation. The thread return value was being initialized to -EAGAIN after the enclosing lock had been released. But that lock is supposed to be atomic with the thread suspend. This opened a window for another racing thread to come by and "wake up" our pending thread (which is fine on its own), set its return value (e.g. to 0 for success) and then have that value clobbered by the thread continuing to suspend itself outside the lock. Melodramatic aside: I continue to hate this arch_thread_return_value_set() API; it needs to die. At best it's a mild optimization on a handful of architectures (e.g. x86 implements it by writing to the EAX register save slot in the context block). Asynchronous APIs are almost always worse than synchronous ones, and in this case it's an async operation that races against literal context switch code that can't use traditional locking strategies. Fixes #39575 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 | ||