Re: LOR route.c:182
From: othermark (atkin901_at_yahoo.com)
Date: 10/30/03
- Previous message: Kris Kennaway: "exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172"
- In reply to: Jiri Mikulas: "LOR route.c:182"
- Next in thread: Sam Leffler: "Re: LOR route.c:182"
- Reply: Sam Leffler: "Re: LOR route.c:182"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: freebsd-current@freebsd.org Date: Thu, 30 Oct 2003 10:30:42 -0800
I'll me too this one..
Another backtrace with a different call sequence (via ipv6), exact same LOR
lock order reversal
1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182
2nd 0xc206537c radix node head (radix node head) @ /usr/src/sys/net
route.c:544
Stack backtrace:
backtrace(c0841847,c206537c,c08472ff,c08472ff,c0847355) at backtrace+0x17
witness_lock(c206537c,8,c0847355,220,c0926300) at witness_lock+0x672
_mtx_lock_flags(c206537c,0,c0847355,220,c8f45868) at _mtx_lock_flags+0xba
rtrequest1(1,c8f45874,c8f458c8,0,c24376b0) at rtrequest1+0x59
rtrequest(1,c24376b0,c24376b0,c8f458cc,405) at rtrequest+0x4a
in6_ifloop_request(1,c2437600,0,c2437600,40) at in6_ifloop_request+0x76
in6_ifaddloop(c2437600,0,c2437600,0,c8f45a84) at in6_ifaddloop+0x50
in6_ifinit(c2000000,c2437600,c8f45a2c,1,1be) at in6_ifinit+0x147
in6_update_ifa(c2000000,c8f45a1c,0,0,20080fe) at in6_update_ifa+0x500
in6_ifadd(c8f45b34,0,40,0,0) at in6_ifadd+0x22a
prelist_update(c8f45b34,c2425740,c1390700,246,c0894d8c) at prelist_updat
+0x3f7
nd6_ra_input(c1390700,28,38,4,1) at nd6_ra_input+0x4ec
icmp6_input(c8f45cac,c8f45c8c,3a,c0629780,38) at icmp6_input+0x9b5
ip6_input(c139f400,0,c084706a,89,0) at ip6_input+0xb97
netisr_processqueue(c0927378,0,c084706a,e5,c1f4d040) at netisr_processqueu
+0x8e
swi_net(0,0,c083c53a,21b,c137e5ac) at swi_net+0x98
ithread_loop(c137cb80,c8f45d48,c083c3ac,311,0) at ithread_loop+0x192
fork_exit(c061f2f0,c137cb80,c8f45d48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xc8f45d7c, ebp = 0 ---
Jiri Mikulas wrote:
> lock order reversal
> 1st 0xc220b690 rtentry (rtentry) @ /usr/src/sys/net/route.c:182
> 2nd 0xc204807c radix node head (radix node head) @
> /usr/src/sys/net/route.c:133
> Stack backtrace:
> backtrace(c087588d,c204807c,c087b88a,c087b88a,c087b8e0) at backtrace+0x17
> witness_lock(c204807c,8,c087b8e0,85,c087b8e0) at witness_lock+0x672
> _mtx_lock_flags(c204807c,0,c087b8e0,85,0) at _mtx_lock_flags+0xba
> rtalloc1(c08d657c,1,10000,3d8,c8f44b30) at rtalloc1+0x79
> rt_setgate(c220b600,c2255a40,c08d657c,1,0) at rt_setgate+0x268
> rtredirect(c08d656c,c08d657c,0,6,c08d658c) at rtredirect+0x1bf
> icmp_input(c1397c00,14,c0666d13,c093af88,c093b280) at icmp_input+0x4ff
> ip_input(c1397c00,0,c087b5f5,89,0) at ip_input+0xae8
> netisr_processqueue(c0961b10,0,c087b5f5,e5,c1f491c0) at
> netisr_processqueue+0x8e
> swi_net(0,0,c0870582,21b,c137e974) at swi_net+0x98
> ithread_loop(c137cd00,c8f44d48,c08703f4,311,0) at ithread_loop+0x192
> fork_exit(c062bbe0,c137cd00,c8f44d48) at fork_exit+0xb4
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xc8f44d7c, ebp = 0 ---
>
>
> _______________________________________________
> 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"
-- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); _______________________________________________ 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"
- Previous message: Kris Kennaway: "exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172"
- In reply to: Jiri Mikulas: "LOR route.c:182"
- Next in thread: Sam Leffler: "Re: LOR route.c:182"
- Reply: Sam Leffler: "Re: LOR route.c:182"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: LOR route vr0
... If I apply your witness patch: ... KDB: stack backtrace: ... I
also get another LOR: ... (freebsd-current) - new LOR to report...
... just ran across a new LOR when trying to unload a module: ... KDB:
stack backtrace: ... (freebsd-current) - Re: 6.1-stable hangs and LORs
... KDB: stack backtrace: ... Due to a lock order reversal (LOR) with the
socket layer, ... group and user filter parameter in conjuction with a Giant-free netstack
... (freebsd-stable) - Re: please test pcm channel patch
... I got 30min into playing tunes and picked the same LOR up not ... (freebsd-current) - Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain"
... but only for short while after the second LOR. ... I cvsuped and built new world
and kernel ... (in single user mode, the system appears to be able to do ...
Stack backtrace: ... (freebsd-current)