| created | 2022-07-31T00:32:00Z |
|---|---|
| begin | 2022-07-23T00:00:00Z |
| end | 2022-07-24T00:00:00Z |
| path | src/sys |
| commits | 4 |
| date | 2022-07-23T05:55:16Z | |||
|---|---|---|---|---|
| author | sdk | |||
| files | src/sys/dev/pckbc/pms.c | log | diff | annotate |
| message |
Discard relative movement packets outside of [-127, 127] range to prevent cursor jumps when using the trackpoint on some lenovo laptops. Known affected models: - Lenovo Thinkpad X13 Gen1 - Lenovo Thinkpad T14(s) - Lenovo Thinkpad E15 Gen3 - Lenovo A475 With help from stsp@ OK stsp@ miod@ deraadt@ bru@ |
|||
| date | 2022-07-23T22:10:58Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/init_main.c | log | diff | annotate |
| src/sys/kern/kern_fork.c | log | diff | annotate | |
| message |
kernel: remove global "randompid" toggle Apparently, we used to created several kthreads before the kernel random number generator was up and running. A toggle, "randompid", was needed to tell allocpid() whether it made sense to attempt to allocate random PIDs. However, these days we get e.g. arc4random(9) into a working state before any kthreads are spawned, so the toggle is no longer needed. Thread: https://marc.info/?l=openbsd-tech&m=165541052614453&w=2 Very nice historical context provided by miod@. probably ok miod@ deraadt@ |
|||
| date | 2022-07-23T22:10:59Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/sys/proc.h | log | diff | annotate |
| message |
kernel: remove global "randompid" toggle Apparently, we used to created several kthreads before the kernel random number generator was up and running. A toggle, "randompid", was needed to tell allocpid() whether it made sense to attempt to allocate random PIDs. However, these days we get e.g. arc4random(9) into a working state before any kthreads are spawned, so the toggle is no longer needed. Thread: https://marc.info/?l=openbsd-tech&m=165541052614453&w=2 Very nice historical context provided by miod@. probably ok miod@ deraadt@ |
|||
| date | 2022-07-23T22:58:51Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/kern/kern_tc.c | log | diff | annotate |
| src/sys/sys/time.h | log | diff | annotate | |
| message |
timecounting: use full 96-bit product when computing elapsed time The timecounting subsystem computes elapsed time by scaling (64 bits) the difference between two counter values (32 bits at most) up into a struct bintime (128 bits). Under normal circumstances it is sufficient to do this with 64-bit multiplication, like this: struct bintime bt; bt.sec = 0; bt.frac = th->tc_scale * tc_delta(th); However, if tc_delta() exceeds 1 second's worth of counter ticks, that multiplication overflows. The result is that the monotonic clock appears to jump backwards. When can this happen? In practice, I have seen it when trying to compile LLVM on an EdgeRouter Lite when using an SD card as the backing disk. The box gets stuck in swap, the hardclock(9) is delayed, and we appear to "lose time". To avoid this overflow we need to compute the full 96-bit product of the delta and the scale. This commit adds TIMECOUNT_TO_BINTIME(), a function for computing that full product, to sys/time.h. The patch puts the new function to use in lib/libc/sys/microtime.c and sys/kern/kern_tc.c. (The commit also reorganizes some of our high resolution bintime code so that we always read the timecounter first.) Doing the full 96-bit multiplication is between 0% and 15% slower than doing the cheaper 64-bit multiplication on amd64. Measuring a precise difference is extremely difficult because the computation is already quite fast. I would guess that the cost is slightly higher than that on 32-bit platforms. Nobody ever volunteered to test, so this remains a guess. Thread: https://marc.info/?l=openbsd-tech&m=163424607918042&w=2 6 month bump: https://marc.info/?l=openbsd-tech&m=165124251401342&w=2 Committed after 9 months without review. |
|||