Re: LOR with iwi and UMA on 7-current

On  4 Sep, Bjoern A. Zeeb wrote:
> On Thu, 1 Sep 2005, Munehiro Matsuda wrote:
> 
> Hi,
> 
>> lock order reversal
>>  1st 0xc0758820 Giant (Giant) _at_ kern/kern_conf.c:310
>>  2nd 0xc1f36b68 iwi0 (network driver) _at_ /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) _at_ net/if.c:1159
>>  2nd 0xc1f36b68 iwi0 (network driver) _at_ /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) _at_ net/route.c:1269
>>  2nd 0xc1f36b68 iwi0 (network driver) _at_ /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) _at_ netinet/tcp_usrreq.c:368
>>  2nd 0xc1f36b68 iwi0 (network driver) _at_ /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) _at_ netinet/tcp_input.c:615
>>  2nd 0xc1f36b68 iwi0 (network driver) _at_ /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.