| created | 2024-08-17T20:08:03Z |
|---|---|
| begin | 2024-08-11T00:00:00Z |
| end | 2024-08-12T00:00:00Z |
| path | src/sys |
| commits | 9 |
| date | 2024-08-11T00:19:00Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/kern/uipc_socket.c | log | diff | annotate |
| message | spelling; ok mvs@ | |||
| date | 2024-08-11T00:49:34Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/kern/kern_timeout.c | log | diff | annotate |
| src/sys/sys/timeout.h | log | diff | annotate | |
| message |
make the timeout_add_foo wrappers more consistent. take uint64_t as the arg type for timeout_add_msec and timeout_add_usec like we do for timeout_add_nsec now. always calculate ticks using uint64_t, and factor out the range checks on the resulting ticks value so it's done consistently. ok claudio@ |
|||
| date | 2024-08-11T01:02:10Z | |||
|---|---|---|---|---|
| author | dlg | |||
| files | src/sys/dev/pci/if_igc.c | log | diff | annotate |
| message |
unbreak igc on strict alignment archs. igc (like other intel nics) only supports a limited range of rx buffer sizes, one of which is 2k like our standard mbuf clusters. however they put the ethernet packet at the start of the provided rx buffer, which means the ip header is misaligned on strict alignment archs if we use the standard 2k mbuf clusters. to avoid wasting too much memory using the next biggest cluster (4k) we have mcl2k2 clusters that pretty much exists for intel nics to use. igc (and probably some other drivers ive touched) was too clever about using mcl2k2 though, which caused panics when trying to use jumbo packets. jan@ fixed this by moving back to 2k clusters, but that broke sparc64 (and probably powerpc64). this dumbs the mcl2k2 handling down a bit so jumbos still work, but adds ETHER_ALIGN back so strict alignment archs also work again. ok bluhm@ |
|||
| date | 2024-08-11T03:27:29Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/pci/drm/include/linux/ioport.h | log | diff | annotate |
| message |
add name member to struct resource needed for newer inteldrm |
|||
| date | 2024-08-11T05:21:52Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/acpi/acpi_x86.c | log | diff | annotate |
| message | put ACPI_SST_WAKING in gosleep() where kettenis asked for | |||
| date | 2024-08-11T05:28:02Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/acpi/acpi_x86.c | log | diff | annotate |
| message | forgot the suspend-time duplication mentioned in 1.25 | |||
| date | 2024-08-11T15:10:53Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/kern/kern_exit.c | log | diff | annotate |
| src/sys/kern/kern_fork.c | log | diff | annotate | |
| src/sys/kern/kern_sysctl.c | log | diff | annotate | |
| src/sys/sys/proc.h | log | diff | annotate | |
| message |
Make exit1() wait sysctl(2) `allprocess' loops. Regardless on wired userland memory, KERN_FILE_BYPID and KERN_FILE_BYUID `allprocess' loops have netlock provided sleep points, so concurrent process exit(1) could crash kernel. The main exit1() problem is that process teardown begins while process is still linked to `allprocess' list, and current code doesn't allow to unlink it first. Wait for concurrent sysctl(2) `allprocess' loops between PS_EXITING bit setting and list unlinking. Both KERN_FILE_BYPID and KERN_FILE_BYUID loops do PS_EXITING check and won't deal with dying process. Concurrent exit1() thread will wait loops keeping process linked to `allprocess' list. Tested with i386 dpb(1) run. Stress tests and ok bluhm. |
|||
| date | 2024-08-11T17:30:28Z | |||
|---|---|---|---|---|
| author | deraadt | |||
| files | src/sys/dev/acpi/acpi_x86.c | log | diff | annotate |
| message | delete correct ACPI_SST_WAKING, pointed out by kettenis | |||
| date | 2024-08-11T21:07:05Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/sys/proc.h | log | diff | annotate |
| message |
Add missing refcnt.h header to fix libkvm build. Reported and ok tb. |
|||