summaryrefslogtreecommitdiffstats
path: root/lib/libcxx/src
diff options
context:
space:
mode:
authorcheloha <cheloha@openbsd.org>2019-12-02 02:24:29 +0000
committercheloha <cheloha@openbsd.org>2019-12-02 02:24:29 +0000
commit1c733b92bb4dc807333a5780ab36f50df04fe341 (patch)
tree8fb59259eab21242d0e478aea72222024c53f54f /lib/libcxx/src
parentoutput_createtmp() remembers the true name, so output_finish() does not (diff)
downloadwireguard-openbsd-1c733b92bb4dc807333a5780ab36f50df04fe341.tar.xz
wireguard-openbsd-1c733b92bb4dc807333a5780ab36f50df04fe341.zip
tc_windup: separate timecounter.tc_freq_adj from timehands.th_adjustment
We currently mix timecounter.tc_freq_adj and timehands.th_adjtimedelta in ntp_update_second() to produce timehands.th_adjustment, our net skew. But if you set a low enough adjfreq(2) adjustment you can freeze time. This prevents ntp_update_second() from running again. So even if you then set a sane adjfreq(2) you cannot unfreeze time without rebooting. If we just reread timecounter.tc_freq_adj every time we recompute timehands.th_scale we avoid this trap. visa@ notes that this is more costly than what we currently do but that the cost itself is negligible. Intuitively, timecounter.tc_freq_adj is a constant skew and should be handled separately from timehands.th_adjtimedelta, an adjustment that we chip away at very slowly. tedu@ notes that this problem is sort-of an argument for imposing range limits on adjfreq(2) inputs. He's right, but I think we should still separate the counter adjustment from the adjtime(2) adjustment, with or without range limits. ok visa@
Diffstat (limited to 'lib/libcxx/src')
0 files changed, 0 insertions, 0 deletions