ntp(9): Avoid more left shift of negative UB.
This logic is, presumably, intended to compute integer arithmetic, so
just write it as *16 instead of <<4. If there's an advantage to
using a machine shift instruction to get the same semantics, the
compiler can do that for us.
Also avoid arithmetic overflow. If set a few lines above,
time_monitor can lie anywhere in the interval [-MAXPHASE,MAXPHASE] =
[-500e6,500e6]. Multiplying by sixteen can therefore overflow the
bounds [-2.2e9,2.2e9] of long on LP32 platforms by a factor of four.
But mtemp >= 256 here, so even if time_monitor*16 overflows the
signed 32-bit range, the result (time_monitor*16)/mtemp will not.
Hence: cast to int64_t for the intermediate computation of
time_monitor*16.
This isn't the end of the analysis: time_monitor can also be set in
hardpps(9) to something else whose bounds aren't as clear to me, but
that only applies under `options PPS_SYNC' which is usually not set.
[4 lines not shown]
dtrace: Avoid uninitialized stack garbage.
Found by:
PR kern/60839: use -ftrivial-auto-var-init
This applies the code change of the following FreeBSD commit, but I
didn't understand the comment so I rewrote it:
commit f222a6b88614db13ae83c8110281e690d1381a4c
Author: Bryan Drewery <bdrewery at FreeBSD.org>
Date: Fri Dec 18 09:58:03 2020 -0800
dtrace: Fix /"string" == NULL/ comparisons using an uninitialized value.
A test of this is funcs/tst.strtok.d which has this filter:
BEGIN
/(this->field = strtok(this->str, ",")) == NULL/
[27 lines not shown]
sys: Use ACTIVE_CC to choose -ftrivial-auto-var-init.
I'm a little fuzzy on the finer semantics of ACTIVE_CC vs
HAVE_GCC/HAVE_LLVM from share/mk/bsd.README, but I think this is the
intended way to conditionalize decisions like this.
PR PR kern/60839: use -ftrivial-auto-var-init
sys: Flip on -ftrivial-auto-var-init=pattern for the kernel build.
Note: HAVE_GCC (if defined) is a major version number, but HAVE_LLVM
(if defined) is yes or no, hence the weird conditionals here.
TBD: Would like to make the choice of `pattern' vs `zero' conditional
on `options DEBUG' or something but that's trickier than I want to
figure out right now; let's just get this on at all to start.
TBD: Kernel modules.
PR kern/60839: use -ftrivial-auto-var-init
t_ipsec_policy: Skip if net.inet.ipsec.enabled doesn't exist too.
Presumably this means the kernel was built without IPsec support.
PR kern/60669: netipsec key_sp2msg buffer overrun
t_sigio: Add diagnostics to fillpipebuf.
For some reason, on some of the releng testbeds, in
socket_local_write_shutdown (and only socket_local_write_shutdown),
it's putting only 7168 (= 8192 - 1024) bytes into a local socket's
buffer before write fails with EAGAIN, but then _after_ fillpipebuf
has returned, write succeeds:
filled 4 with 7168 bytes
[thread] waiting for barrier
[thread] giving other thread a head start
checking that write fails with 35 (Resource temporarily unavailable)...
*** Check failed: /tmp/build/2026.10.02.08.45.07-i386/src/tests/lib/libc/sys/t_sigio.c:368: Expected true value in (nwrit = write(writefd, &c, 1)) == -1
*** Check failed: /tmp/build/2026.10.02.08.45.07-i386/src/tests/lib/libc/sys/t_sigio.c:369: nwrit != -1: nwrit=1
[thread] shutdown(SHUT_RD)
[thread] shutdown
But on my machine, and presumably on other testbeds where the test
passes, it fills the whole 8192 bytes before EAGAIN, and the next
[24 lines not shown]
t_fdrestart: Skip signal handler; let atf take SIGALRM as failure.
Safer than calling atf_tc_fail in the SIGALRM handler, and the xfail
is finer-grained this way (any check failure will be reported as test
failure; only SIGALRM will be reported as expected).
PR kern/57659: closing pipe writefd fails to wake concurrent write on
same writefd
Pullup the following, requested by kre in ticket #507:
external/public-domain/tz/dist/CONTRIBUTING up to 1.1.1.11
external/public-domain/tz/dist/Makefile up to 1.7
external/public-domain/tz/dist/NEWS up to 1.10
external/public-domain/tz/dist/README up to 1.4
external/public-domain/tz/dist/TZDATA_VERSION up to 1.48
external/public-domain/tz/dist/africa up to 1.5
external/public-domain/tz/dist/asia up to 1.17
external/public-domain/tz/dist/backward up to 1.13
external/public-domain/tz/dist/backzone up to 1.6
external/public-domain/tz/dist/europe up to 1.7
external/public-domain/tz/dist/northamerica up to 1.9
external/public-domain/tz/dist/southamerica up to 1.6
external/public-domain/tz/dist/theory.html up to 1.8
external/public-domain/tz/dist/version up to 1.21
external/public-domain/tz/dist/zone.tab up to 1.8
external/public-domain/tz/dist/zone1970.tab up to 1.9
external/public-domain/tz/dist/zonenow.tab up to 1.10
[3 lines not shown]
Pull up following revision(s) (requested by jnemeth in ticket #506):
external/bsd/ntp/dist/ntpd/ntp_proto.c: revision 1.21
Fix overly aggressive rejection of valid servers.
Patch taken from https://bugs.ntp.org/3877 . This patch is likely to be
included in the next release.
Fixes PR bin/60831
Pull up following revision(s) (requested by hgutch in ticket #1348):
share/examples/npf/host-npf.conf: revision 1.13
share/examples/npf/host-npf.conf: revision 1.14
share/examples/npf/soho_gw-npf.conf: revision 1.22
Fix a couple more ``blacklist --> blocklist''
More blacklist --> blocklist
Pull up following revision(s) (requested by hgutch in ticket #505):
share/examples/npf/host-npf.conf: revision 1.13
share/examples/npf/host-npf.conf: revision 1.14
share/examples/npf/soho_gw-npf.conf: revision 1.22
Fix a couple more ``blacklist --> blocklist''
More blacklist --> blocklist
Pull up following revision(s) (requested by skrll in ticket #504):
sys/dev/ic/pl181var.h: revision 1.4
sys/arch/evbarm/ifpga/plmmc_ifpga.c: revision 1.3
evbarm/INTEGRATOR_CP: establish interrupt handler for PL181 controller
PR/60818 plmmc_ifpga.c does not establish interrupt handler for PL181 controller
Capture the handle returned from ifpga_intr_establish - someone might
write the code to call ifpga_intr_disestablish.
Pull up following revision(s) (requested by skrll in ticket #503):
sys/arch/mips/mips/pmap_machdep.c: revision 1.41
sys/arch/mips/mips/cpu_subr.c: revision 1.68
mips: create ci_shootdowncpus early so it's available for MP pmap_update
When using ENABLE_MIPS_4KB_PAGE on OCTEON with an MULTIPROCESSOR kernel
an early pmap_update is triggered which requires ci_shootdowncpus to be
vailable.
Pull up the following, requested by skrll in ticket #502:
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/Makefile up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-cubieboard6.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-guitar-bb-rev-b.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-guitar.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-labrador-base-m.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-labrador-v2.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-roseapplepi.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500-sparky.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/actions/owl-s500.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/airoha/Makefile up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/airoha/en7523-evb.dts up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/airoha/en7523.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/allwinner/Makefile up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/allwinner/axp152.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/allwinner/axp209.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/allwinner/axp223.dtsi up to 1.1.1.1
sys/external/gpl2/dts/dist/arch/arm/boot/dts/allwinner/axp22x.dtsi up to 1.1.1.1
[7624 lines not shown]
