blockable sleep lock (sleep mutex) 16

[John Baldwin]

On Monday 02 February 2009 7:33:08 am Nikola Knežević wrote:
> On 30 Jan 2009, at 18:11 , Nikola Knežević wrote:
> 
> > This is the message buffer:
> > Unread portion of the kernel message buffer:
> > panic: blockable sleep lock (sleep mutex) 16 @ /usr/src/sys/vm/ 
> > uma_core.c:1834
> 
> > Any hints where I should search for the cause?
> 
> 
> Ok, I solved this problem. I had a critical_enter/exit surrounding  
> code which was calling a lot of mallocs. Now, I'm getting another  
> message, which doesn't make any sense:
> 
> ---8<---
> --- trap 0, rip = 0, rsp = 0xffffffff87834d30, rbp = 0 ---
> uma_zalloc_arg: zone "256" with the following non-sleepable locks held:
> exclusive sleep mutex click_instance r = 0 (0xffffff00051b4540) locked  
> @ sched.cc:441
> --->8---
> 
> It says "non-sleepable locks", yet it classifies click_instance as  
> sleep mutex. I think witness code should emit messages which are more  
> clear.

It is confusing, but you can't do an M_WAITOK malloc while holding a mutex.  
Basically, sleeping actually means calling "*sleep() (such as mtx_sleep()) or 
cv_*wait*()".  Blocking on a mutex is not sleeping, it's "blocking".  Some 
locks (such as sx(9)) do "sleep" when you contest them.  In the scheduler, 
sleeping and blocking are actually quite different (blocking uses turnstiles 
that handle priority inversions via priority propagation, sleeping uses sleep 
queues which do not do any of that).  The underyling idea is that mutexes 
should be held for "short" periods of time, and that any sleeps are 
potentially unbounded.  Holding a mutex while sleeping could result in a 
mutex being held for a long time.

-- 
John Baldwin