Date: Sat, 12 Mar 2005 17:49:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: LOR with rtentry and rl0 Message-ID: <Pine.NEB.3.96L.1050312174746.84033A-100000@fledge.watson.org> In-Reply-To: <20050312161309.GA65207@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 12 Mar 2005, Steve Kargl wrote: > I don't recall seeing this LOR posted. It may be related to rwatson's > recent work in the socket layer. It's not impossible I introduced a bug that results in this. Is this reproduceable? Is there any chance you could break into DDB, do "show witness", and send me the output? FWIW, generally speaking the lock order is "stack locks before interface locks" so that the stack can hold locks over calls into the device driver. Bugs in device drivers sometimes cause device driver locks to be held over calls into the stack. However, lock leaks can also result in what appears to be a lock order reversal to WITNESS, but is actually a lock leak... Thanks, Robert N M Watson > > > lock order reversal > 1st 0xc2f098a0 rtentry (rtentry) @ /usr/src/sys/netinet/if_ether.c:445 > 2nd 0xc2c33f00 rl0 (network driver) @ /usr/src/sys/modules/rl/../../pci/if_rl.c:1444 > KDB: stack backtrace: > witness_checkorder(c2c33f00,9,c084cffd,5a4,c2c338fc) at witness_checkorder+0x5e9 > _mtx_lock_flags(c2c33f00,0,c084cffd,5a4,c2c33800) at _mtx_lock_flags+0x54 > rl_start(c2c33800,0,c06c19af,184,202a94c) at rl_start+0x37 > > ether_output_frame(c2c33800,c2e69400,6,ea0a5a04,c062f4e4) at ether_output_frame+0x23c > ether_output(c2c33800,c2e69400,ea0a5a28,0,c2f6c3c8,2,1,c06b2302,32b,c2f6fa10,c2f6fa84) at ether_output+0x26f > arprequest(ea0a5b20,c2c3d4ab,c06c254d,1bd,ea0a5a84) at arprequest+0x10b > arpresolve(c2c33800,c2f09840,c2e69500,ea0a5b1c,ea0a5aa0) at arpresolve+0x30d > ether_output(c2c33800,c2e69500,ea0a5b1c,c2f09840,c06bb96b) at ether_output+0x32b > ip_output(c2e69500,0,ea0a5b18,1,0) at ip_output+0xa39 > udp_send(c2f06bac,0,c2e69500,0,0) at udp_send+0x40e > sosend(c2f06bac,0,ea0a5c44,c2e69500,0) at sosend+0x600 > > kern_sendit(c2f6fa10,d,ea0a5cc0,0,0) at kern_sendit+0xee > sendit(ea0a5cc0,0,80f902b,0,0) at sendit+0x5f > sendto(c2f6fa10,ea0a5d14,18,3ff,6) at sendto+0x53 > syscall(2f,2f,2f,bfbfe210,482abf84) at syscall+0x13d > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (133, FreeBSD ELF32, sendto), eip = 0x4822463f, esp = 0xbfbfd52c, ebp = 0xbfbfd558 --- > -- > Steve > -- > Steve > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1050312174746.84033A-100000>