LOR in /usr/src/sys/netinet/in.c:972

John Baldwin jhb at FreeBSD.org
Thu Sep 15 12:59:49 PDT 2005


On Thursday 15 September 2005 03:24 pm, Robert Watson wrote:
> 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...

I'm working on that. :)

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org


More information about the freebsd-current mailing list