Skip to content
Permalink
Browse files

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 <andrew.j.ross@intel.com>
  • Loading branch information...
andyross authored and andrewboie committed May 31, 2019
1 parent e6af0f8 commit 84473630f47ee1441e84b0ac3cf1d0f4c384c63e
Showing with 13 additions and 1 deletion.
  1. +13 −1 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

0 comments on commit 8447363

Please sign in to comment.
You can’t perform that action at this time.