if_tuntap: make SIOCIFDESTROY interruptible

[kevans]

Summary

There's no good justification to permanently hang a thread until the
tunnel can be destroyed. Make it interruptible so that the admin can
^C it and remedy the situation if something erroneously has the tunnel
open, rather than forcing them to open another shell to resolve it.

[markj]

sys/net/if_tuntap.c

632–633

Hmm, shouldn't this be a while loop?

637

I would just use cv_wait() here so that the locking protocol is consistent. Then we can unconditionally unlock below instead of having the tp->tun_busy == 0 || may_intr check.

[zlei]

Shall we firstly signal the application that the tuntap device is going to be shutdown and destroyed and secondly poll the status of tun_busy ?

Or just return EBUSY if applications can decline interface destroying ?

[kevans]

(Sorry, I just realized I forgot about this review entirely)

In D39740#905088, @zlei wrote:

Shall we firstly signal the application that the tuntap device is going to be shutdown and destroyed and secondly poll the status of tun_busy ?

I'm not sure what that would look like, exactly.

Or just return EBUSY if applications can decline interface destroying ?

I think that's probably fine (in the may_intr case, since the !may_intr case is usually "we're evacuaating the vnet"), but I'd prefer to do as a follow-up so that we're not changing the semantics that much in a minor release (where-as, we can kinda fix the current situation a little bit)

[kevans]

Use a loop, set error before (it'll either get clobbered or remain untouched),
and just consistently keep it locked leaving the loop.