From owner-freebsd-current@FreeBSD.ORG Wed Jan 21 11:56:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3415416A4CE for ; Wed, 21 Jan 2004 11:56:31 -0800 (PST) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE8D43D1D for ; Wed, 21 Jan 2004 11:56:29 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 15262 invoked from network); 21 Jan 2004 19:56:29 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 21 Jan 2004 19:56:29 -0000 Received: from 10.50.40.205 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i0LJuOM0020216; Wed, 21 Jan 2004 14:56:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Kris Kennaway , current@FreeBSD.org Date: Wed, 21 Jan 2004 14:10:11 -0500 User-Agent: KMail/1.5.4 References: <20040121182138.GA40579@xor.obsecurity.org> In-Reply-To: <20040121182138.GA40579@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401211410.11497.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: panic: mutex pipe mutex not owned at ../../../kern/sys_pipe.c:414 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2004 19:56:31 -0000 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 <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org