panic: mutex pipe mutex not owned at ../../../kern/sys_pipe.c:414

John Baldwin jhb at
Wed Jan 21 11:56:31 PST 2004

On Wednesday 21 January 2004 01:21 pm, Kris Kennaway wrote:
> Well, I managed to panic bento in under 12 hours of use, after Joe had
> been using it for the past 2 months without problems :-)
> panic: mutex pipe mutex not owned at ../../../kern/sys_pipe.c:414
> cpuid = 0;
> Debugger("panic")
> Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
> db> trace
> Debugger(c068e1db,0,c068d7dc,e45d8bb4,100) at Debugger+0x55
> panic(c068d7dc,c06911d0,c0691d1e,19e,c0691d1e) at panic+0x156
> _mtx_assert(ce82bd40,1,c0691d1e,19e,0) at _mtx_assert+0xec
> pipe_direct_write(cb040ac0,e45d8c7c,c0691d1e,372,1) at
> pipe_direct_write+0x541 pipe_write(cb02e83c,e45d8c7c,c692ed80,0,c7b0e640)
> at pipe_write+0x2d7 dofilewrite(c7b0e640,cb02e83c,1,8067000,31bd) at
> dofilewrite+0xfb
> write(c7b0e640,e45d8d10,c06a40eb,3ee,3) at write+0x6e
> syscall(2f,2f,2f,8067000,31bd) at syscall+0x2c0
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (4, FreeBSD ELF32, write), eip = 0x280ef2ef, esp = 0xbfbfe74c,
> ebp = 0xbfbfe768 --- db>
> It is running 5.2-BETA from Dec 1.  Any ideas?
> Kris "Bug Magnet" Kennaway

Well, the pipe locking code looks weird.  pipe_write() locks the read pipe 
(rpipe), and then later drops the lock for the write pipe (wpipe) around a 
function call.  It seems to think that the read pipe and write pipe are using 
the same lock.  This does seem to be the case from the pipe() syscall, but it 
sure makes following the code very confusing.  I don't see a code path where 
the lock is not held that pipe_direct_write() is called from pipe_write().  
You can try using KTR and KTR_LOCK if this is reproducible and seeing if you 
can see where the lock was dropped in the 'show ktr' output from ddb.

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-current mailing list