From 84473630f47ee1441e84b0ac3cf1d0f4c384c63e Mon Sep 17 00:00:00 2001 From: Andy Ross Date: Fri, 31 May 2019 12:35:46 -0700 Subject: [PATCH] kernel/thread_abort: Swap, don't reschedule when aborting _current The z_reschedule() call (as of the accompanying fix) will not swap away from a thread if called with a nested irq lock held. But for the specific case of aborting the current thread, we absolutely need to swap regardless of how many locks the thread that just aborted might have held. So call z_swap() explicitly here. This preserves the existing z_reschedule() call in other circumstances for compatibility with existing test cases, but adds a note explaining why it's there when the only obvious reason for it is already covered. Signed-off-by: Andy Ross --- kernel/thread_abort.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/kernel/thread_abort.c b/kernel/thread_abort.c index eeb3db9f84c..61bca7ff28d 100644 --- a/kernel/thread_abort.c +++ b/kernel/thread_abort.c @@ -43,7 +43,19 @@ void z_impl_k_thread_abort(k_tid_t thread) z_thread_single_abort(thread); z_thread_monitor_exit(thread); - z_reschedule(&lock, key); + if (thread == _current && !z_is_in_isr()) { + z_swap(&lock, key); + } else { + /* Really, there's no good reason for this to be a + * scheduling point if we aren't aborting _current (by + * definition, no higher priority thread is runnable, + * because we're running!). But it always has been + * and is thus part of our API, and we have tests that + * rely on k_thread_abort() scheduling out of + * cooperative threads. + */ + z_reschedule(&lock, key); + } } #endif