tun/tap: close race between destroy/ioctl handler

[kevans]

Summary

It seems that there should be a better way to handle this, but this seems to be the more common approach and it should likely get replaced in all of the places it happens... Basically, thread 1 is in the process of destroying the tun/tap while thread 2 is executing one of the ioctls that requires the tun/tap mutex and the mutex is destroyed before the ioctl handler can acquire it.

This is only one of the races described/found in PR 233955.

PR: 233955

[kevans]

Actually functional, after a little bit more coffee and testing... previous version caused trivial deadlock as follows:

1.) ifconfig tun1 create
2.) ifconfig tun1 10.10.1.1 10.10.1.2
3.) ifconfig tun1 destroy

*_destroy only needs to hold ioctl_sx long enough to invalidate the if_softc, while the ioctl handler needs to hold it to guarantee liveness until it's done. Minimize the destroy bits.

[ae]

LGTM.