created | 2024-08-11T01:37:53Z |
---|---|
begin | 2024-08-06T00:00:00Z |
end | 2024-08-07T00:00:00Z |
path | src/sys |
commits | 11 |
date | 2024-08-06T08:44:54Z | |||
---|---|---|---|---|
author | claudio | |||
files | src/sys/kern/kern_event.c | log | diff | annotate |
src/sys/kern/kern_exec.c | log | diff | annotate | |
src/sys/kern/kern_exit.c | log | diff | annotate | |
src/sys/kern/kern_fork.c | log | diff | annotate | |
src/sys/kern/kern_sig.c | log | diff | annotate | |
src/sys/sys/event.h | log | diff | annotate | |
src/sys/sys/proc.h | log | diff | annotate | |
message |
Stop using KERNEL_LOCK to protect the per process kqueue list Instead of the KERNEL_LOCK use the ps_mtx for most operations. If the ps_klist is modified an additional global rwlock (kqueue_ps_list_lock) is required. This includes the knotes with NOTE_FORK and NOTE_EXIT since in either cases a ps_klist is changed. In the NOTE_FORK | NOTE_TRACK case the call to kqueue_register() can sleep this is why a global rwlock is used. Adjust the reaper() to call knote_processexit() without KERNEL_LOCK. Double lock idea from visa@ OK mvs@ |
date | 2024-08-06T09:07:15Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/arch/riscv64/riscv64/intr.c | log | diff | annotate |
message |
The devicetree spec says in section 2.4: If an interrupt-generating device does not have an interrupt-parent property, its interrupt parent is assumed to be its devicetree parent. Implement this aspect of the spec in the same way as Linux does by not just looking at the immediate parent but keep on walking up the tree until we hit a node with an "interrupt-controller" property or a node that has an "interrupt-parent" property. similar diff as committed for arm64 a couple of days ago ok jca@ |
date | 2024-08-06T12:36:54Z | |||
---|---|---|---|---|
author | mvs | |||
files | src/sys/kern/kern_sysctl.c | log | diff | annotate |
message |
Unlock KERN_CLOCKRATE. Read-only access to local `clkinfo' filled with immutable data. ok bluhm |
date | 2024-08-06T15:03:36Z | |||
---|---|---|---|---|
author | patrick | |||
files | src/sys/dev/sdmmc/sdhc.c | log | diff | annotate |
message |
On the RK3588 eMMC controller it appears that after a failed command a completion signal shows up some time after the error signal. This can lead to the case that when the next command is being executed, the old completion signal is still recorded and the driver may think the command already executed. Resetting the status before executing a new command makes sense, albeit it's technically still possible that the controller issues another completion signal. It shouldn't happen because a reset was issued and we're also waiting for the command and data inhibit bits to be cleared, but who knows. This makes the eMMC come up reliably. ok kettenis@ |
date | 2024-08-06T16:56:09Z | |||
---|---|---|---|---|
author | bluhm | |||
files | src/sys/net/pf.c | log | diff | annotate |
src/sys/netinet/ip_input.c | log | diff | annotate | |
message |
Unlock sysctl net.inet.ip.directed-broadcast. ip_directedbcast is read once in either ip_input() or pf_test() during packet processing. So writing the variable does not need net lock. OK mvs@ |
date | 2024-08-06T17:30:04Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/dev/usb/xhci.c | log | diff | annotate |
message |
Some Intel xhci(4) controllers don't fully power down unless they've seen a "save state" command. So use that command when we suspend (and don't reset the controller at that point such that it doesn't forget about it). Note that on resume we don't restore the state. Instead we just reset the controller and bring it up from scratch. There isn't much state to save anyway since we detach all USB devices when we suspend. ok mlarkin@, deraadt@ |
date | 2024-08-06T17:38:56Z | |||
---|---|---|---|---|
author | kettenis | |||
files | src/sys/dev/acpi/acpi_x86.c | log | diff | annotate |
src/sys/dev/acpi/acpibtn.c | log | diff | annotate | |
src/sys/dev/acpi/acpidev.h | log | diff | annotate | |
src/sys/dev/acpi/acpivar.h | log | diff | annotate | |
src/sys/dev/acpi/dsdt.c | log | diff | annotate | |
message |
Some laptops will generate an EC event shortly after we attempt to enter a low power S0 idle state. Since we register the EC GPE as a wakeup GPE this means we'll wake up immediately. Unfortunately we have to register that GPE as a wakeup GPE otherwise many laptops won't wake up when the user opens the lid (and some laptops won't wake up at all). So add some code to handle EC events while suspended and introduce the concept of wakeup AML notify handlers. Register the acpibtn(4) notify handlers as wakeup notify handlers such that we wake up. We'll go back to sleep immediately if we wake up for any other EC event. ok mlarkin@, deraadt@ |
date | 2024-08-06T18:41:20Z | |||
---|---|---|---|---|
author | claudio | |||
files | src/sys/kern/kern_exit.c | log | diff | annotate |
message |
Revert the knote_processexit() bits of the diff. It introduced a small window where a knote is available but PS_ZOMBIE is not yet set (causing waitpid() to not return that pid). Requested by jca@ and deraadt@ |
date | 2024-08-06T20:13:58Z | |||
---|---|---|---|---|
author | mvs | |||
files | src/sys/kern/uipc_usrreq.c | log | diff | annotate |
message |
Use atomic_load_int(9) for unlocked read access to net.unix.*space sysctl(2) variables. ok bluhm |
date | 2024-08-06T20:14:56Z | |||
---|---|---|---|---|
author | mvs | |||
files | src/sys/kern/uipc_socket.c | log | diff | annotate |
message |
For consistency with other similar sysctl(2) variables use atomic_load_int(9) while loading `somaxconn' and `sominconn'. ok bluhm |
date | 2024-08-06T20:15:53Z | |||
---|---|---|---|---|
author | mvs | |||
files | src/sys/netinet/udp_usrreq.c | log | diff | annotate |
message |
Unlock `udpctl_vars'. `udp_sendspace' and `udp_recvspace' are integers which read-only accessed in udp_attach(). `udpcksum' read-only accessed in udp_output(). No netlock required to modify them through sysctl(2). ok bluhm |