| Previous | Next |
| KERN_LOCK_OWNED | KERN_SEMAPHORE_DESTROYED |
KERN_LOCK_OWNED_SELF
Self-ownership exposes a reentrancy problem
KERN_LOCK_OWNED_SELF means the caller already owns the lock. This is different from contention with another thread: a simple wait cannot resolve it because the same thread must first unwind, release, or avoid the second incompatible lock operation.
The result identifies recursion or reentrancy in code that assumes a non-recursive lock contract, often through a callback, notification, error path, or helper that silently reaches the same guarded resource.
What to inspect
- Capture the original acquisition stack and the second acquisition stack.
- Check whether a callback executes before the first critical section has been exited.
- Review cleanup and tracing code for hidden calls back into the guarded subsystem.
- Do not replace a non-recursive lock with a recursive one unless the protected data invariants support reentrancy.
References
- Apple XNU: kern_return.h
- Apple Kernel Programming Guide: locks and synchronization
- Apple Kernel Programming Guide: Mach tasks and threads
Looking for a different code? Search another status or error code.
