Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

kernel: Panic on attempting to release a semaphore with interrupts disabled...

Browse Source 
... and B_DO_NOT_RESCHEDULE unset. We already have equivalent panics
for mutexes and condition variables, so it seems to make sense to
check for this too.

There have been some bug reports recently about hard deadlocks with
symptoms (i.e. kernel debugger can't even be summoned) that match
"interrupt handler thread was context-switched while holding interrupt
lock," and this is the only major remaining path to that without
such a check.

This would have also helped me with recent FreeBSD driver porting;
I forgot to pass the flag once and deadlocked my system in precisely
this manner.
This commit is contained in:
Augustin Cavalier 2019-01-07 22:13:35 -05:00
parent 1c1efa6f2f
commit 2e33d79d38
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/system/kernel/sem.cpp
View File

@ -925,6 +925,12 @@ release_sem_etc(sem_id id, int32 count, uint32 flags)
return B_BAD_SEM_ID; return B_BAD_SEM_ID;
if (count <= 0 && (flags & B_RELEASE_ALL) == 0) if (count <= 0 && (flags & B_RELEASE_ALL) == 0)
return B_BAD_VALUE; return B_BAD_VALUE;
#if KDEBUG
if ((flags & B_DO_NOT_RESCHEDULE) == 0 && !are_interrupts_enabled()) {
panic("release_sem_etc(): called with interrupts disabled and "
"rescheduling allowed for sem_id %ld", id);
}
#endif
InterruptsLocker _; InterruptsLocker _;
SpinLocker semLocker(sSems[slot].lock); SpinLocker semLocker(sSems[slot].lock);