Andy Ross 1202810119 kernel/sched: _thread_priority_set needs to be sched_lock aware ... This API doesn't use the normal thread priority comparison itself, so doesn't get the magic that thread_base.prio provides. If called when another thread should be run, this would preempt the current thread always, even if the scheduler lock was taken. That was benign until recent spinlockifiation exposed it: a mutex in the philosophers test run in preempt_only mode would swap away while holding a spinlock (which used to work with irq locks) and fail later with a "recursive" spinlock assert. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>		2019-02-08 14:49:39 -05:00
..
include
atomic_c.c
CMakeLists.txt
compiler_stack_protect.c
device.c
errno.c
idle.c
init.c
int_latency_bench.c
Kconfig
Kconfig.power_mgmt
mailbox.c	kernel/mbox: Spinlockify	2019-02-08 14:49:39 -05:00
mem_domain.c
mem_slab.c
mempool.c
msg_q.c	kernel/msg_q: Spinlockify	2019-02-08 14:49:39 -05:00
mutex.c	kernel/mutex: Spinlockify	2019-02-08 14:49:39 -05:00
pipes.c	kernel/pipe: Spinlockify	2019-02-08 14:49:39 -05:00
poll.c
queue.c
sched.c	kernel/sched: _thread_priority_set needs to be sched_lock aware	2019-02-08 14:49:39 -05:00
sem.c
smp.c
stack.c	kernel/stack: Spinlockify	2019-02-08 14:49:39 -05:00
system_work_q.c
thread_abort.c
thread.c
timeout.c
timer.c	kernel/timer: Spinlockify	2019-02-08 14:49:39 -05:00
userspace_handler.c
userspace.c	kernel/userspace: Spinlockification	2019-02-08 14:49:39 -05:00
version.c
work_q.c