| Commit message (Collapse) | Author | Files | Lines |
|
OK mpi@ anton@
|
|
OK otto
|
|
ok tedu@, visa@
|
|
|
|
display; remove the why bogus status message; ok florian@
|
|
From Chris Wilson
e80e88ef6057c7947409bda9898387d25e54aaa9 in linux 4.19.y/4.19.87
2d691aeca4aecbb8d0414a777a46981a8e142b05 in mainline linux
|
|
From Evan Quan
8a67fbf6597122c4a5e2c48716bc441364357eef in linux 4.19.y/4.19.87
355d991cb6ff6ae76b5e28b8edae144124c730e4 in mainline linux
|
|
|
|
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@
|
|
need to replay it.
|
|
|
|
|
|
and then a void * for calling the hexdump() operator
with bluhm
|
|
OK mpi@
|
|
Same fix as for the IPv6 case. Fixes a regression in ports/net/openvpn
spotted by landry@, ok bluhm@
|
|
|
|
ok millert@ deraadt@
|
|
field names in sense mode structs.
|
|
'const' from the only two 'const int' instances.
|
|
|
|
Handles typical split-horzizon setups. ok florian@
|
|
|
|
|
|
Change Elf64_Half from a uint32_t type to a uint16_t type. The size of
structs do not change as the previous uses of Elf64_Half become
Elf64_Word (uint32_t).
Remove Elf64_Quarter as 16 bit values now use Elf64_Half.
Replace Elf_Byte use with unsigned char.
Change some uses of Elf64_Xword to Elf64_Addr (both uint64_t).
Corrects behaviour with libelf where the file size of a symtab section
came back as 26 not 24 as libelf determines this by the size of a the
involved types not the size of the struct in exec_elf.h. As a result
libelf's elf_getdata() returned ELF_E_SECTION due to the size of the
section not being a multiple of the file size of the section type.
This occurred with the new runtime linker for radeon shaders in
Mesa 19.2.
Sync description of Elf32 and Elf64 types in elf(5) with FreeBSD and
adjust types in structs mentioned.
ok guenther@ deraadt@
|
|
ok reyk@
|
|
It can now be a symlink.
ok naddy@ solene@ kn@
|
|
committed by mistake as part of an unrelated change
|
|
|
|
|
|
|
|
OK deraadt@
|
|
haven't crossed over the ABI break as easily as expected.
|
|
|
|
- man page is bgpd, not openbgpd
ok deraadt
|
|
|
|
|
|
|
|
|
|
ok florian@
|
|
and thus must be sent last.
ok reyk@
|
|
ok patrick@
|
|
will read from
OK kn@
|
|
`romfile' if -r is used, but since I'm only unveiling after that file is
actually opened there's no need to unveil it as well.
OK deraadt@ kn@
|
|
"stdio rpath sendfd" so that it can call {l,}stat/open and sendfd for imsg_*
in order to send fds to the child proc which is already pledged by recvfd to
receive them
OK brynet@ deraadt@
|
|
rwsleep(9) with PCATCH and rw_enter(9) with RW_INTR without the kernel
lock. In addition, now tsleep(9) with PCATCH should be safe to use
without the kernel lock if the sleep is purely time-based.
Tested by anton@, cheloha@, chris@
OK anton@, cheloha@
|
|
there might be others still working.
Make sure check_resolver() handles this correctly.
|
|
ok markus
|
|
|
|
interpreted only prefixlen. Also accept netmask for IPv6. This
is consistent to our man page and the route(8) command.
OK benno@
|
|
Analogue to amd64's vmctl create, this command creates sparse disk image
files of the given size.
This is less error prone than creating full files with dd(1), but comes
with other caveats - still, it is worth having around.
Further refinements yet to come; vmctl and ldomctl should also behave more
alike in the future, as briefly discussed with kettenis and deraadt.
|