Date: Thu, 15 Sep 2005 20:24:17 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-current@freebsd.org, dan.cojocar@gmail.com Subject: Re: LOR in /usr/src/sys/netinet/in.c:972 Message-ID: <20050915202308.H75005@fledge.watson.org> In-Reply-To: <200509151422.04459.jhb@FreeBSD.org> References: <b37cb09705090307285418dd1e@mail.gmail.com> <200509151422.04459.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 15 Sep 2005, John Baldwin wrote: > On Saturday 03 September 2005 10:28 am, Dan Cojocar wrote: >> Hello, >> Here is my second lor for today :) that i didn't find on >> http://sources.zabbadoz.net/freebsd/lor.html >> I get this when i run dhclient on cdce0 interface. It's harmless, because I >> obtain an valid ip and everything is working ok. >> >> lock order reversal >> 1st 0xc06a2e40 in_multi_mtx (in_multi_mtx) @ /usr/src/sys/netinet/in.c:972 >> 2nd 0xc0655660 Giant (Giant) @ /usr/src/sys/net/if.c:1998 >> KDB: stack backtrace: >> witness_checkorder(c0655660,9,c0612eef,7ce,12c) at witness_checkorder+0x51c >> _mtx_lock_flags(c0655660,0,c0612eef,7ce,c) at _mtx_lock_flags+0x54 >> if_addmulti(c1a67800,d5729afc,d5729af8,3cc,c1bf0780) at if_addmulti+0x260 >> in_addmulti(d5729b40,c1a67800,1,2cc,c1b8bbc8) at in_addmulti+0x66 >> in_ifinit(c1f53190,0,0,0,d5729b90) at in_ifinit+0x5bc >> in_control(c1f8b000,8040691a,c1f53180,c1a67800,c1aa0e10) at >> in_control+0xfaa ifioctl(c1f8b000,8040691a,c1f53180,c1aa0e10,2) at >> ifioctl+0x15a >> soo_ioctl(c1f5e000,8040691a,c1f53180,c1f65200,c1aa0e10) at soo_ioctl+0x2e8 >> ioctl(c1aa0e10,d5729d04,c,422,3) at ioctl+0x118 >> syscall(3b,3b,3b,808e3a0,0) at syscall+0x13d >> Xint0x80_syscall() at Xint0x80_syscall+0x1f >> --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x807f49b, esp = 0xbfbfe5bc, >> ebp = 0xbfbfee28 --- > > This is a real LOR caused by the fact that in_addmulti() holds the > in_multi_mtx() lock across the call to if_addmulti() and if_addmulti() > will acquire Giant for non-MPsafe drivers around calls into their ioctl > routine. I think that to better expose these issues, the various > conditional-Giant macros need to include a witness_warn() to make sure > only sleepable locks and/or Giant are held when the lock macro is > invoked. The right strategy here may in fact be to eliminate Giant acquisition by network device drivers... Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050915202308.H75005>