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

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Wed, 21 Jan 2004 14:10:11 -0500
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_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Wed Jan 21 2004 - 10:56:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:39 UTC