> Date: Thu, 10 Aug 2023 17:42:35 +0900
> From: Kengo NAKAHARA <k-nakah...@iij.ad.jp>
>
> Could you tell me how you test this fix for future reference?
I asked skrll@ to boot a VM with vmxnet3 and hammer on it with a
combination of:
1. dhcp
2. host$ nc -l 54321 </dev/urandom >/dev/null
guest$ nc host 54321 </dev/urandom >/dev/null
3. for i in `jot 4`; do
jot 100 | while read i; do
ifconfig vmxnet0 down
ifconfig vmxnet0 up
done &
done
wait
and then see if the network continued functioning.
However, I didn't do anything to verify that we could trigger all the
problems that I noticed by code inspection. I didn't do that mostly
because I'd been sitting on this patch for a year, and I didn't want
it to languish indefinitely with obvious bugs lurking in vmxnet(4).
Here are a couple more things that it would be good to do:
1. Create a sysctl knob to simulate watchdog failure and trigger
reset. I don't think we tested this path at all, but it's a common
bug with an easy fix -- defer to workqueue. Some other drivers
have a sysctl knob like this: wm(4), bge(4).
2. Verify that SIOCADDMULTI and SIOCDELMULTI don't deadlock when run
concurrently with ifconfig up/down.
vmxnet(4) still has a serious bug: the `core lock' can still lead to a
deadlock with reset and softint. It should be removed from most uses,
and be limited to cover only mii transactions like I did for usbnet(4)
last year.
