pretty much all of tun_wakeup needs to be protected with KERNEL_LOCK
tun_wakeup is called from the network stack, which generally runs
with NET_LOCK, not KERNEL_LOCK, which is a problem when it calls
into things like csignal or kq code. this started causing corruption
and panics of a list inside the kq code, which got reported to
this version of the fix is ok mpi@ (even though he hasn't seen it)
an earlier but far trickier fix was ok visa@
the bug was reported by Olivier Antoine, and again by jmc@ privately.
sprinkle some KERNEL_ASSERT_LOCKED()
operations that tweak the kq_head and kq_count need to be serialised
against the kevent syscall which also fumbles with the list and
these asserts would have made it extremely obvious where the tun(4)
bug was. for half the time of the bug report about it we werent
even sure it was tun(4)
discussed with mpi@ jmatthew@
add a KERNEL_ASSERT_LOCKED() to ptsignal
it obviously needs to be called with the kernel lock held, so it
makes sense to check that so we can unlock more code without
introducing bugs that shoot us in the face in the indeterminate
csignal is basically a wrapper around ptsignal, so calls to that
without the kernel lock should be caught by this too.
discussed with mpi@ on bugs@
Avoid using an expression which resolves to an int in a bool context
when a nested macro is called with an expression argument.
Prompted by -Wint-in-bool-context with gcc 8. ok kettenis@
Use the proper UAC-v2.0 request to read the device controls.
Fixes STALL errors in mixer requests causing the mixer to be unusable.
With help from Claus