kernek: don't allow mutex ops in ISRs
Mutex operations check ownership against _current. But in an ISR, _current is just whatever thread was interrupted when the ISR fired. Explicitly do not allow this. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This commit is contained in:
parent
4cdaa71444
commit
6af9793f0c
2 changed files with 9 additions and 0 deletions
|
@ -3610,6 +3610,8 @@ __syscall int k_mutex_init(struct k_mutex *mutex);
|
|||
* A thread is permitted to lock a mutex it has already locked. The operation
|
||||
* completes immediately and the lock count is increased by 1.
|
||||
*
|
||||
* Mutexes may not be locked in ISRs.
|
||||
*
|
||||
* @param mutex Address of the mutex.
|
||||
* @param timeout Waiting period to lock the mutex,
|
||||
* or one of the special values K_NO_WAIT and
|
||||
|
@ -3631,6 +3633,9 @@ __syscall int k_mutex_lock(struct k_mutex *mutex, k_timeout_t timeout);
|
|||
* the calling thread as many times as it was previously locked by that
|
||||
* thread.
|
||||
*
|
||||
* Mutexes may not be unlocked in ISRs, as mutexes must only be manipulated
|
||||
* in thread context due to ownership and priority inheritance semantics.
|
||||
*
|
||||
* @param mutex Address of the mutex.
|
||||
*
|
||||
* @retval 0 Mutex unlocked.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue