In nat64_find_route[46] handle NHF_GATEWAY flag and use destination
address from next hop to do link layer address lookup.
PR: 255928
Reviewed by: melifaro
Obtained from: Yandex LLC
MFC after: 1 week
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D31680
Cannon and Comet Lake PCHs have their PMC hidden, so when reading
the ACPI Base Address fails, we assume a default value.
Obtained from: Semihalf
Sponsored by: Stormshield
Similar to the recent addition of ALTQ support to if_vlan.
Reviewed by: donner
Obtained from: pfsense
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31675
Test that ALTQ can prioritise one type of traffic over another. Do this
by establishing a slow link and saturating it with ICMP echos.
When prioritised TCP connections reliably go through. When not
prioritised TCP connections reliably fail.
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
This pushes the bulk of the rx servicing into a single loop that's only
slightly convoluted, and it addresses a problem with rx handling in the
process. If we hit a tx interrupt while we're processing, we'd
previously drop the frame on the floor completely and ultimately
timeout, increasing boot time on particularly busy hosts as we keep
having to backoff and resend.
After this patch, we don't seem to hit timeouts at all on zoo anymore
though loading a 27M kernel is still relatively slow (~1m20s).
Reviewed by: tsoome
Triage by: Ash Gokhale <ashfixit gmail com>
Sponsored By: National Bureau of Economic Research
Sponsored by: Klara, Inc.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31512
Implementing VOP_DEALLOCATE to allow hole-punching in the same manner as
POSIX shared memory's fspacectl(SPACECTL_DEALLOC) support.
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D31684
The partial page invalidation code is factored out to be a separate
helper from tmpfs_reg_resize().
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D31683
- pget()/pfind() will acquire the PID hash bucket locks, which are
sleepable sx locks, but this means that the sigio mutex cannot be held
while calling these functions. Instead, use pget() to hold the
process, after which we lock the sigio and proc locks, respectively.
- funsetownlst() assumes that processes cannot be registered for SIGIO
once they have P_WEXIT set. However, pfind() will happily return
exiting processes, breaking the invariant. Add an explicit check for
P_WEXIT in fsetown() to fix this. [1]
Fixes: f52979098d ("Fix a pair of races in SIGIO registration")
Reported by: syzkaller [1]
Reviewed by: kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31661
Commit 9e202d036d introduces incompatible changes to
fspacectl(2), vn_deallocate(9) and VOP_DEALLOCATE(9)'s
rmsr.r_offset/*offset return value.
Sponsored by: The FreeBSD Foundation
rmsr.r_offset now is set to rqsr.r_offset plus the number of bytes
zeroed before hitting the end-of-file. After this change rmsr.r_offset
no longer contains the EOF when the requested operation range is
completely beyond the end-of-file. Instead in such case rmsr.r_offset is
equal to rqsr.r_offset. Callers can obtain the number of bytes zeroed
by subtracting rqsr.r_offset from rmsr.r_offset.
Sponsored by: The FreeBSD Foundation
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D31677
The main purpose of this test is to verify that we can use ALTQ on top
of if_vlan, but while we're here we also exercise the CBQ code. There's
already a basis test for HFSC, so it makes sense to test another
algorithm while we test if_vlan.
Reviewed by: donner
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D31649
In implicit mode assignment of slot number and tracking id is performed
automatically on each synchronization requested by device driver.
This is done with creation of intermediate buffer for multitouch events.
This buffer holds untracked events until synchronization is requested by
device driver. It is needed as touch assigment requires
knowledges of all touch positions pushed in current and previous reports.
MFC after: 2 weeks
Touch tracking is a process of assignment of unique trackingID to each
initiated contact on the surface. Keeping the trackingIDs persistent
across multitouch reports requires solving of so called Euclidian
Bipartite Matching problem.
This commit imports EBM-solver implementation based on Dinitz-Kronrod
algorithm to find minimum cost matching between contacts listed in two
consecutive reports.
Obtained from: OpenBSD
MFC after: 2 weeks
with using of unioned anonymous structure.
Access to the same data by using different members of union generally
works despite it is not supported by C specs.
Also add helper function to report entire slot state.
MFC after: 2 weeks
As fuzz has already been applied on multitouch event processing.
This allows to remove existing workaround for double fuzz procesing.
MFC after: 2 weeks
1. Move touch count reporting helpers to utils. They are not multitouch.
2. Use evdev_mt prefix for private multitouch support routines.
3. Use int instead of int32_t where fixed size is not required.
4. Export some internal functions.
This change should be no-op.
MFC after: 2 weeks
As is done in the target, require that DataSN values are consecutive
and in-order. If an out of order Data-In PDU is received, force a
session reconnect. In addition, when a SCSI Response PDU is received,
verify that the ExpDataSN field matches the count of Data-In PDUs
received for this command. If not, force a session reconnect.
Reviewed by: mav
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D31594
This avoids any unnecessary works in such case.
Sponsored by: The FreeBSD Foundation
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D31655
Somewhat ironically, there are strict aliasing violations in Clang,
which can result in the following assertion failure:
Assertion `*(NamedDecl **)&Data == ND && "PointerUnion mangles the NamedDecl pointer!"' failed.
Upstream's clang/CMakeLists.txt specifically (not LLVM as a whole)
passes -fno-strict-aliasing if the compiler is not Clang, and this fixes
the above issue.
This was seen when cross-building from Linux using a bootstrap
compiler, but likely also affects worlds built with a new enough
external GCC toolchain.
MFC after: 1 week
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D31533
If MK_DEBUG_FILES=no then the Clang link rule has clang as .TARGET,
rather than clang.full, causing the implicit ${CFLAGS.${.TARGET:T}} to
be CFLAGS.clang, and thus pull in flags intended for when your compiler
is Clang, not when linking Clang itself. This doesn't matter if your
compiler is in fact Clang, but it breaks using GCC as, for example,
bsd.sys.mk adds -Qunused-arguments to CFLAGS.clang. This is seen when
trying to build a bootstrap toolchain on Linux where GCC is the system
compiler.
Thus, introduce a new internal NO_TARGET_FLAGS variable that is set by
Clang to disable the addition of these implicit flags. This is a bigger
hammer than necessary, as flags for .o files would be safe, but that is
not needed for Clang.
Note that the same problem does not arise for LDFLAGS when building LLD
with BFD, since our build produces a program called ld.lld, not plain
lld (unlike upstream, where ld.lld is a symlink to lld so they can
support multiple different flavours in one binary).
Suggested by: sjg
Fixes: 31ba4ce889 ("Allow bootstrapping llvm-tblgen on macOS and Linux")
MFC after: 1 week
Reviewed by: dim, imp, emaste
Differential Revision: https://reviews.freebsd.org/D31532
Because MK_LLDB=no is in BSARGS, the bootstrap-tools recursive make does
not add lldb-tblgen to _clang_tblgen, causing it to not be built. This
means that the build currently always uses the host's lldb-tblgen
(which, whilst currently it appears to work, could in future break if
TableGen backends are added or altered) and, if it doesn't exist (either
because the current FreeBSD system was built with it disabled, or you're
building on macOS/Linux), fails. Linux and macOS cross-builds used to
work simply because LLDB was previously in BROKEN_OPTIONS when building
on non-FreeBSD.
Instead, move MK_LLDB=no from BSARGS to XMAKE. This ensures that the
lib/clang build in cross-tools continues to not build LLDB parts for the
bootstrap toolchain (both to save time/space on FreeBSD, and because our
vendored LLDB does not include the macOS and Linux host files so those
would fail to build).
The DIRDEPS target is updated to move MK_LLDB=no from the BSARGS block
that mirrors Makefile.inc1 to the line that disables additional
toolchain components. The DIRDEPS build likely suffers from the same
issue currently, but having never used it and not being familiar with
how it works I am leaving that as-is. If it does suffer from the same
issue it should be easily reproducible by renaming /usr/bin/lldb-tblgen
or moving it to a directory not in PATH.
Fixes: 31ba4ce889 ("Allow bootstrapping llvm-tblgen on macOS and Linux")
MFC after: 1 week
Reviewed by: dim, emaste, imp
Differential Revision: https://reviews.freebsd.org/D31531
Currently we override MK_CLANG_BOOTSTRAP to no so we don't build a
bootstrap compiler, but subdirectories don't see that and so the hack in
bsd.sys.mk to prefer our includes over Clang's resource dir for external
toolchains is not enabled unless you use -DWITHOUT_CLANG_BOOTSTRAP
explicitly on top of XCC (which tools/build/make.py does not do),
causing duplicate definition errors when building rtld-elf due to the
use of -ffreestanding (Clang's stdint.h will use the system one when
hosted, but its own when freestanding, and only has glibc's preprocessor
guards, not FreeBSD's).
This broke when dropping CLANG_BOOTSTRAP from BROKEN_OPTIONS.
Fixes: 31ba4ce889 ("Allow bootstrapping llvm-tblgen on macOS and Linux")
MFC after: 1 week
Reviewed by: imp, arichardson
Differential Revision: https://reviews.freebsd.org/D31529
The removed text claimed that memcpy is implemented using bcopy and thus
strings may overlap. Use of bcopy is an implementation detail that is
no longer true, even if the implementation (on some archs) does allow
overlap.
In any case behaviour is undefined per the C standard if memcpy is
called with overlapping objects, and this man page already claimed that
src and dst may not overlap.
Reviewed by: kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D31192
