Describe the bug

I have found a path where we attempt to recursively lock _sched_spinlock (something that is not allowed in Zephyr).

It occurs under very specific circumstances--aborting a user thread that has dynamic objects but there are threads waiting for the memory that aborting it would be free.

I stumbled across this when I tried refactoring z_unpend_all() so that it had _sched_spinlock locked for its whole loop.

Regression

• This is a regression.

Steps to reproduce

Inspection.

1. k_thread_abort() calls z_thread_abort().
2. z_thread_abort() locks _sched_spinlock <<<< Important
3. z_thread_abort() calls z_thread_halt()
4. z_thread_halt() calls halt_thread()
5. halt_thread() calls k_thread_perms_all_clear() when CONFIG_USERSPACE=y
6. k_thread_perms_all_clear() calls clear_perms_cb() foreach object wordlist.
7. clear_perms_cb() calls unref_check()
8. unref_check() calls k_free() when CONFIG_DYNAMIC_OBJECTS=y
9. k_free() calls k_heap_free()
10. k_heap_free() calls z_unpend_all()
11. z_unpend_all() wakes any threads blocked waiting for memory from the heap
12. z_unpend_all() calls z_unpend_thread()
13. z_unpend_thread() calls z_unpend_thread_no_timeout()
14. z_unpend_thread_no_timeout() locks _sched_spinlock <<<< Recursive attempt.

Relevant log output

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

Current SHA: 77eb31e

Additional Context

No response