I have a few simple shell scripts to test the tx/rx panics and to make
sure the config path locking is still sane. Both were run with INVARIANTS
kernels. The tx/rx panics are easily reproducible using two bhyve VMs
with the tap interfaces connected via IF_BRIDGE(4). Additionally Isilon
will be running this through an internal vlan-locking test suite shortly.
Basic create_destroy script that creates a bunch of vlans, propogates
an lladdr change, sets the MTU, then destroys them:
```
#!/bin/sh
for i in `seq 1 200`
do
ifconfig "vlan$i" create
ifconfig "vlan$i" vlan $i vlandev vtnet0
ifconfig "vlan$i" "203.$i.113.1/24"
done
ifconfig vtnet0 ether "00:a0:98:e7:7e:f6"
for i in `seq 1 200`
do
ifconfig "vlan$i" mtu 1000 &
ifconfig "vlan$i" destroy &
done
```
The following two scripts transmit over vlans and iteratively
destroys it on the receiving side:
```
#!/bin/sh
set -x
set -e
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.11/24
dd if=/dev/zero bs=32k count=1000000 | nc -N 203.0.113.10 8000
```
```
#!/bin/sh
set -x
set -e
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.10/24
nc -l -k 8000 > /dev/null &
set s=''
read s
while true
do
ifconfig vlan0 destroy
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.10/24
sleep 1
done
```
The following two do the opposite:
```
#!/bin/sh
set -x
set -e
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.11/24
dd if=/dev/zero bs=32k count=1000000 | nc -N 203.0.113.10 8000 &
set s=''
read s
while true
do
ifconfig vlan0 destroy
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.11/24
sleep 1
done
```
```
#!/bin/sh
set -x
set -e
ifconfig vlan0 create
ifconfig vlan0 vlandev vtnet0 vlan 42
ifconfig vlan0 203.0.113.10/24
nc -l -k 8000 > /dev/null
```
As of 7/7/17 Isilon has completed our internal regression testing of these changes against HEAD as of r310194. Those regression tests involve creating/destroying vlan interfaces on top of physical interfaces and passing traffic between them. Additionally all of the configuration ioctls paths are tested. This is all done with an INVARIANTS kernel to note any WITNESS warnings.
A version of these changes, using just an rmlock(9) but covering broadly the same areas, has been in production with Isilon customers for over a year.