| created | 2019-10-26T13:51:35Z |
|---|---|
| begin | 2019-10-21T00:00:00Z |
| end | 2019-10-22T00:00:00Z |
| path | src/sys |
| commits | 7 |
| date | 2019-10-21T10:02:41Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/dev/usb/usbdi.c | log | diff | annotate |
| message |
Mark recycled USB `xfer' as NOT_STARTED to not confuse HCD abort methods. Prevent an infinite loop when aborting ulpt(4)'s pipe after an I/O error. Found by and ok stsp@ |
|||
| date | 2019-10-21T10:24:01Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_fork.c | log | diff | annotate |
| src/sys/sys/proc.h | log | diff | annotate | |
| src/sys/sys/sched.h | log | diff | annotate | |
| message |
Move `p_estcpu' to the region copied during fork & kill scheduler_fork_hook(). While here reorder some fields in 'struct proc' to avoid size grow. ok bluhm@, visa@ |
|||
| date | 2019-10-21T16:32:51Z | |||
|---|---|---|---|---|
| author | jcs | |||
| files | src/sys/dev/acpi/acpivout.c | log | diff | annotate |
| message |
When incrementing or decrementing screen brightness, don't just adjust by 1 BCL level as there may be 100 levels. Find the next brightness level that is at least 5% up or down and use that. ok kettenis |
|||
| date | 2019-10-21T16:45:48Z | |||
|---|---|---|---|---|
| author | jcs | |||
| files | src/sys/dev/acpi/acpithinkpad.c | log | diff | annotate |
| message |
On newer ThinkPads reporting HKEY version > 1, don't claim wscons backlight controls so that acpivout can. This allows using all of the fine-grained backlight BCL steps defined in ACPI (usually 100) instead of the dozen or so available through acpithinkpad's proprietary ACPI or CMOS interfaces. This is also needed for future amdgpu work. |
|||
| date | 2019-10-21T20:52:32Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/conf/GENERIC | log | diff | annotate |
| message |
Add sxipwm(4) and pwmbl(4). Thse two drivers together add support for the backlight controller on the Pinebook. ok patrick@, jsg@ |
|||
| date | 2019-10-21T20:52:33Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/dev/fdt/files.fdt | log | diff | annotate |
| src/sys/dev/fdt/pwmbl.c | log | diff | annotate | |
| src/sys/dev/fdt/sxipwm.c | log | diff | annotate | |
| message |
Add sxipwm(4) and pwmbl(4). Thse two drivers together add support for the backlight controller on the Pinebook. ok patrick@, jsg@ |
|||
| date | 2019-10-21T23:02:05Z | |||
|---|---|---|---|---|
| author | sashan | |||
| files | src/sys/net/bpf.c | log | diff | annotate |
| src/sys/net/bpfdesc.h | log | diff | annotate | |
| message |
put bpfdesc reference counting back, revert change introduced in 1.175 as: BPF: remove redundant reference counting of filedescriptors Anton@ made problem crystal clear: I've been looking into a similar bpf panic reported by syzkaller, which looks somewhat related. The one reported by syzkaller is caused by issuing ioctl(SIOCIFDESTROY) on the interface which the packet filter is attached to. This will in turn invoke the following functions expressed as an inverted stacktrace: 1. bpfsdetach() 2. vdevgone() 3. VOP_REVOKE() 4. vop_generic_revoke() 5. vgonel() 6. vclean(DOCLOSE) 7. VOP_CLOSE() 8. bpfclose() Note that bpfclose() is called before changing the vnode type. In bpfclose(), the `struct bpf_d` is immediately removed from the global bpf_d_list list and might end up sleeping inside taskq_barrier(systq). Since the bpf file descriptor (fd) is still present and valid, another thread could perform an ioctl() on the fd only to fault since bpfilter_lookup() will return NULL. The vnode is not locked in this path either so it won't end up waiting on the ongoing vclean(). Steps to trigger the similar type of panic are straightforward, let there be two processes running concurrently: process A: while true ; do ifconfig tun0 up ; ifconfig tun0 destroy ; done process B: while true ; do tcpdump -i tun0 ; done panic happens within few secs (Dell PowerEdge 710) OK @visa, OK @anton |
|||