| created | 2019-06-12T22:34:48Z |
|---|---|
| begin | 2019-05-01T00:00:00Z |
| end | 2019-05-02T00:00:00Z |
| path | src/sys |
| commits | 5 |
| date | 2019-05-01T06:11:46Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/net/if_tun.c | log | diff | annotate |
| message |
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 bugs@. 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. |
|||
| date | 2019-05-01T06:22:39Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/kern/kern_event.c | log | diff | annotate |
| message |
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 count too. 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@ |
|||
| date | 2019-05-01T06:26:42Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/kern/kern_sig.c | log | diff | annotate |
| message |
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 future. 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@ |
|||
| date | 2019-05-01T07:22:24Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/include/linux/wait.h | log | diff | annotate |
| message |
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@ |
|||
| date | 2019-05-01T14:51:40Z | |||
|---|---|---|---|---|
| author | ratchov | |||
| files | src/sys/dev/usb/uaudio.c | log | diff | annotate |
| message |
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 |
|||