Hi, This is regarding a lock order reversal which is already reported in http://ipv4.sources.zabbadoz.net/freebsd/lor/134.html. Pasting the witness backtrace here: lock order reversal 1st 0xc1787144 inp (raw6inp) @ sys/netinet6/icmp6.c:1895 2nd 0xc1788090 inp (rawinp) @ sys/netinet6/icmp6.c:1895
KDB: stack backtrace: kdb_backtrace(c07dcab1,c1788090,c07f043f,c07e928d,c07ec854) at kdb_backtrace+0x2e witness_checkorder(c1788090,9,c07ec854,767,12b) at witness_checkorder+0x6c3 _mtx_lock_flags(c1788090,0,c07ec854,767,c25d5658) at _mtx_lock_flags+0x8a icmp6_rip6_input(cc9fcbec,28,38,1,0) at icmp6_rip6_input+0xb6 icmp6_input(cc9fcc94,cc9fcc34,3a,0,0) at icmp6_input+0xdd4 ip6_input(c25d5600,0,c07e3c86,e8,c08cf944) at ip6_input+0xee7 Is this a valid issue or a spurious one. This seems to be flagged when the icmp6_rip6_input code traverses the pcb list which contains v4 and v6 pcbs. How is the witness lock order established other than the static one ? Is this established on the first locking order encountered (where LOP_NEWORDER flag is passed)?. Regards Reji _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"