From owner-freebsd-current Fri Dec 6 19:29:35 2002 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 6C8EA37B401 for ; Fri, 6 Dec 2002 19:29:34 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2ED443EB2 for ; Fri, 6 Dec 2002 19:29:33 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.6/8.12.5) with SMTP id gB73TSBF034048; Fri, 6 Dec 2002 22:29:28 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 6 Dec 2002 22:29:28 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Kris Kennaway Cc: Lars Eggert , current@FreeBSD.ORG Subject: Re: LOR: filedesc structure -> pipe mutex In-Reply-To: <20021207022253.GA69717@rot13.obsecurity.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Dec 2002, Kris Kennaway wrote: > I'm getting this too: > > Local package initialization:lock order reversal > 1st 0xc449ad34 filedesc structure (filedesc structure) @ /local0/src-client/sys/kern/sys_generic.c:901 > 2nd 0xc4146780 pipe mutex (pipe mutex) @ /local0/src-client/sys/kern/sys_pipe.c:1239 > Debugger("witness_lock") > Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 > db> trace > Debugger(c03efc85,c4146780,c04192dc,c04192dc,c0419d33) at Debugger+0x54 > witness_lock(c4146780,8,c0419d33,4d7,c0291b89) at witness_lock+0x667 > _mtx_lock_flags(c4146780,0,c0419d33,4d7,c418b4ec) at _mtx_lock_flags+0xb1 > pipe_poll(c418b4ec,40,c420ad00,c3f5cb60,c420ad00) at pipe_poll+0x40 > selscan(c3f5cb60,d7a29b98,d7a29b88,7,4) at selscan+0x12e > kern_select(c3f5cb60,7,8076190,0,0) at kern_select+0x36f > select(c3f5cb60,d7a29d10,c043094c,407,5) at select+0x66 > syscall(2f,2f,2f,8076190,1e) at syscall+0x28e > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (93, FreeBSD ELF32, select), eip = 0x2829a433, esp = 0xbfbff4dc, ebp = 0xbfbffda0 --- > db> Given that selscan() seems to rely on holding the file descriptor lock for the duration of the scan, it seems that the file descriptor lock is intended to be grabbed before the pipe mutex in the lock order. The reversal you're seeing is probably therefore the "right order" rather than the "wrong order". To properly diagnose this, you probably want to hard code that order in Witness's lock order list in subr_witness so that a warning is generated earlier. This reversal is presumably the second order found by the kernel, which is the point at which (if the first order isn't hard-coded) that a violation is first found. Using "show witness" you can inspect how the lock order was constructed -- I've always found the output a bit confusing, so if it's a simple order reversal (involving direct lock relationships between two locks), hard-coding it is easier. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message