Date: Sun, 4 Sep 2005 14:34:48 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: bzeeb-lists@lists.zabbadoz.net Cc: haro@h4.dion.ne.jp, freebsd-current@FreeBSD.org Subject: Re: LOR with iwi and UMA on 7-current Message-ID: <200509042134.j84LYmLI028855@gw.catspoiler.org> In-Reply-To: <Pine.BSF.4.53.0509041548010.93099@e0-0.zab2.int.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Sep, Bjoern A. Zeeb wrote: > On Thu, 1 Sep 2005, Munehiro Matsuda wrote: > > Hi, > >> lock order reversal >> 1st 0xc0758820 Giant (Giant) @ kern/kern_conf.c:310 >> 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 > > added this LOR with ID 150: > http://sources.zabbadoz.net/freebsd/lor.html#150 > >> lock order reversal >> 1st 0xc07a7060 ifnet (ifnet) @ net/if.c:1159 >> 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1643 > > added with LOR ID 151: > http://sources.zabbadoz.net/freebsd/lor.html#151 > >> lock order reversal >> 1st 0xc22c2bb8 rtentry (rtentry) @ net/route.c:1269 >> 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 > > added with LOR ID 152: > http://sources.zabbadoz.net/freebsd/lor.html#152 > >> lock order reversal >> 1st 0xc230a1f8 inp (tcpinp) @ netinet/tcp_usrreq.c:368 >> 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 > > added with LOR ID 153: > http://sources.zabbadoz.net/freebsd/lor.html#153 > > though quite similar to LOR ID 128: > http://sources.zabbadoz.net/freebsd/lor.html#128 > > >> lock order reversal >> 1st 0xc07a8a6c tcp (tcp) @ netinet/tcp_input.c:615 >> 2nd 0xc1f36b68 iwi0 (network driver) @ /home/haro/tmp/sys-7/modules/iwi/../../dev/iwi/if_iwi.c:1587 > > added with LOR ID 154: > http://sources.zabbadoz.net/freebsd/lor.html#154 These, and probably most or all of the recent LORs involving network driver, have the same cause as LOR #148. The lock order reported in #148 is incorrect, but it was only detected by witness when I added jhb's patch to the witness code. It is triggered by adding the DEVICE_POLLING kernel option. This particular reversal introduces a loop into the lock ordering, and without the witness patch, witness only detects the reversal when the loop is finally closed by code that grabs a lock in the correct order, and with the previous lock happens to traverse the final edge of the loop.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509042134.j84LYmLI028855>