kern/52255: if_tun panic in tun_clone_destroy()

[paul%whooppee.com@localhost]

>Number:         52255
>Category:       kern
>Synopsis:       if_tun panic in tun_clone_destroy()
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 24 03:35:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 7.99.71
>Organization:
+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 7.99.71 NetBSD 7.99.71 (SPEEDY 2017-05-11 00:01:07 UTC) #0: Thu May 11 04:22:38 UTC 2017 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
When built with lockdebug, tun_clone_destroy() encounters a panic when
calling kmem_intr_free() to free the device's softc.  It seems that there
is still an active lock contained within the softc.

A little investigation shows that the lock must actually be inside the
'struct ifnet'; the only lock inside the tun-specific portion of the softc
is the tun_lock, which is already being kmutex_destroy()d before the call
to kmem_intr_free().  But I don't see anywhere where the actual kmutex is
contained inside 'struct ifnet' - just pointers to various lock things.

	
>How-To-Repeat:
1. Bring up a tunnel (I use openvpn for this)
2. Shut the system down, which should cause the tunnel to be destroyed
	
>Fix:
Not known.

XXX
Note that other cloning network devices might well have a similar bug!
	

>Unformatted: