Date: Fri, 6 Dec 2002 22:29:28 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Kris Kennaway <kris@obsecurity.org> Cc: Lars Eggert <larse@ISI.EDU>, current@FreeBSD.ORG Subject: Re: LOR: filedesc structure -> pipe mutex Message-ID: <Pine.NEB.3.96L.1021206222148.5166T-100000@fledge.watson.org> In-Reply-To: <20021207022253.GA69717@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1021206222148.5166T-100000>