It was originally in contrib, and moved to usr.sbin in 6692aa840c1f; I always thought lib would make more sense but never got around to moving it.
Reviewed by: cy
Differential Revision: https://reviews.freebsd.org/D41504
Update Intel irdma driver to version 1.2.17-k
Notable changes:
- pf-reset handling improvements, including fixes in communication with if_ice(4)
- avoid racing when handling various events
- adding sw stats sysctls
- hand over pe_criterr handling from ice(4) to irdma(4)
- debug prints adjustments
- fix crash after changes in irdma_add_mqh_ifa_cb
Signed-off-by: Bartosz Sobczak <bartosz.sobczak@intel.com>
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
MFC after: 1 month
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D41425
Highlights:
- Some style fixes
- Bumped mbbuf in istrsenvisx() to MB_LEN_MAX to avoid VLAs
- mbslength cannot go negative, so make it unsigned
- Further bounds checking & fix an additional overrun, with dlen == 0
- Avoid duplicate call to wcslen(start)
GoogleTest 1.14.0 now requires C++14 to build. Change
`googletest.test.inc.mk` to reflect this requirement.
Adjust the build integration logic to handle the new version of
GoogleTest (add/remove headers/sources as needed).
Tighten down warnings via `CXXFLAGS.clang` instead of ignoring all
warnings. Some new warnings snuck in after I did my last round of fix
submissions upstream.
Also address some overlinking added in the previous version import by
removing superfluous libraries.
===============================
Expect WhenDynamicCastToTest.AmbiguousCast to fail
This change reapplies the expected failure from 1.10.0.
Ref: https://github.com/google/googletest/issues/2172
MFC after: 2 weeks
Reviewed by: asomers, emaste
Differential Revision: https://reviews.freebsd.org/D41399
Merge commit '8ef491440fcaec96f899d73e08873426c78583a4' into googletest-v1.14.0-import
The previous incarnation of this would call wcrtomb() on the destination
buffer, and only check for overflow *after* it's happened.
Additionally, the conversion error / VIS_NOLOCALE path also didn't check
for overflow, and the overflow check at the end didn't account for the
fact that we still need to write a NUL terminator afterward.
Start by only doing the multibyte conversion into mbdst directly if we
have enough buffer space to guarantee it'll fit. An additional
MB_CUR_MAX buffer has been stashed on the stack to write into if we're
cutting it close at the end of the buffer, since we don't really have a
good way to determine the length of the wchar_t without just doing the
conversion. We'll do the conversion into the buffer that's guaranteed
to fit, then copy it over if the copy won't overflow.
The byte-for-byte overflow is a little bit easier, as we simply check
for overflow with each byte written and make sure we can still NUL
terminate after.
Tests added to exercise these edge cases.
Reviewed by: des
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D41328
The function ibv_query_device_ex is static inline, it is not exported
from the dso. With lld 16, which is much more picky about versioning and
undefined symbols, this becomes an error.
The ibv_register_driver driver symbol is explicitly versioned in
sources, it is non-existent in un-versioned object files.
Sponsored by: NVidia networking
MFC after: 1 week
The FreeBSD driver support for clang tested explicitly for 32-bit
Intel, MIPS, or PowerPC targets where /usr/lib32/libcrt1.o was
present to decide whether -m32 should use /usr/lib32. At jrtc27's
suggestion, simply test for a 32-bit platform rather than adding
arm to the list. Upstreamed as
3450272fc2
Bump the freebsd version to force a bootstrap build. This is one
step in adding support for -m32 on arm64.
Reviewed by: jrtc27, brooks, dim
Differential Revision: https://reviews.freebsd.org/D40943
Libarchive 3.7.0
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
MFC after: 2 weeks
PR: 272567 (exp-run)
[builtins][Mips] Un-break FreeBSD build of __clear_cache
Commit 674a17e9bbe8 ("MIPS/compiler_rt: use synci to flush icache on
r6") completely removed the OS-specific guards under the guise of "For
pre-r6, we can use cacheflush libc function, which is same on Linux and
FreeBSD." However, the code in question had guards for Linux and
OpenBSD, not Linux and FreeBSD, and FreeBSD does not have a cacheflush
libc function as claimed, so this was neither the statement they
intended to make nor was it sufficient justification for making the code
completely unconditional. Whilst the upcoming FreeBSD 14 release has
dropped support for MIPS, FreeBSD 13 has support for it.
Fix this by only calling cacheflush on the OSes where it was previously
called, and not on other OSes where it either definitely isn't available
(FreeBSD) or is unknown (any other OS than the three mentioned in this
commit).
This is only needed for MFC'ing, as mips has been removed from
14-CURRENT.
PR: 271047
MFC after: immediately
Intentionally or not, but the libwrap was written in such manner that
if your /etc/hosts.allow doesn't have any domain names, neither smart
keywords like LOCAL or KNOWN, then it will not try to resolve the
client address during the hosts check. This was achieved with the
NOT_INADDR() check that matched IPv4 addresses/prefixes. Extend this
to also skip resolve if client list token looks like IPv6.
Reviewed by: philip, emaste
PR: 269456
Differential revision: https://reviews.freebsd.org/D40070
Important changes (relevant to FreeBSD):
#1840 year 2038 fix for pax archives on platforms with 64-bit time_t
#1873 bsdunzip ported to libarchive from FreeBSD
#1894 read support for zstd compression in 7zip archives
#1918 ARM64 filter support in 7zip archives
Obtained from: libarchive
Libarchive commit: ee45796171324519f0c0bfd012018dd099296336
Libarchive tag: v3.7.0
[PowerPC] Replace PPCISD::VABSD cases with generic ISD::ABDU(X,Y) node
A move towards using the generic ISD::ABDU nodes on more backends
Also support ISD::ABDS for v4i32 types using the existing signbit flip trick
PowerPC has a select(icmp_ugt(x,y),sub(x,y),sub(y,x)) -> abdu(x,y) combine that I intend to move to DAGCombiner in a future patch.
The ABS(SUB(X,Y)) -> PPCISD::VABSD(X,Y,1) v4i32 combine wasn't legal (https://alive2.llvm.org/ce/z/jc2hLU) - so I've removed it, having already added the legal sub nsw tests equivalent.
Differential Revision: https://reviews.llvm.org/D142313
This fixes a "Wasn't expecting to be able to lower this!" fatal error
when compiling graphics/opencv for PowerPC.
Requested by: pkubaj
PR: 271047
MFC after: 1 month
[clang] Reset FP options before template instantiation
AST nodes that may depend on FP options keep them as a difference
relative to the options outside the AST node. At the moment of
instantiation the FP options may be different from the default values,
defined by command-line option. In such case FP attributes would have
unexpected values. For example, the code:
template <class C> void func_01(int last, C) {
func_01(last, int());
}
void func_02() { func_01(0, 1); }
#pragma STDC FENV_ACCESS ON
caused compiler crash, because template instantiation takes place at the
end of translation unit, where pragma STDC FENV_ACCESS is in effect. As
a result, code in the template instantiation would use constrained
intrinsics while the function does not have StrictFP attribute.
To solve this problem, FP attributes in Sema must be set to default
values, defined by command line options.
This change resolves https://github.com/llvm/llvm-project/issues/63542.
Differential Revision: https://reviews.llvm.org/D154359
Requested by: pkubaj
PR: 265755, 265758
MFC after: 1 month
See commit 8fad2cda93 ("bsd.compat.mk: Provide new CPP and sub-make
variables") for the context behind this change.
Reviewed by: brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40923
[Clang] Show type in enum out of range diagnostic
When the diagnostic for an out of range enum value is printed, it
currently does not show the actual enum type in question, for example:
v8/src/base/bit-field.h:43:29: error: integer value 7 is outside the valid range of values [0, 3] for this enumeration type [-Wenum-constexpr-conversion]
static constexpr T kMax = static_cast<T>(kNumValues - 1);
^
This can make it cumbersome to find the cause for the problem. Add the
enum type to the diagnostic message, to make it easier.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D152788
PR: 271047
MFC after: 1 month
This reapplies upstream commit c0141f3c300f by Aaron Ballman:
Downgrade implicit int and implicit function declaration to warning only
The changes in Clang 15.0.0 which enabled these diagnostics as a
warning which defaulted to an error caused disruption for people
working on distributions such as Gentoo. There was an explicit request
to downgrade these to be warning-only in Clang 15.0.1 with the
expectation that Clang 16 will default the diagnostics to an error.
See
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213
for more details on the discussion.
See https://reviews.llvm.org/D133800 for the public review of these
changes.
As noted in the upstream discussion, there are many programs that fail
to configure or build correctly, if these warnings are turned into
errors by default.
Note that most affected programs in ports are relatively old, and are
unlikely to be fixed by actually adjusting their declarations, but by
compiling with -std=gnu89, which downgrades the errors back to warning
again. Lots of tedious work for very little gain.
[clang][BFloat] Avoid redefining bfloat16_t in arm_neon.h
As of https://reviews.llvm.org/D79708, clang-tblgen generates `arm_neon.h`,
`arm_sve.h` and `arm_bf16.h`, and all those generated files will contain a
typedef of `bfloat16_t`. However, `arm_neon.h` and `arm_sve.h` include
`arm_bf16.h` immediately before their own typedef:
#include <arm_bf16.h>
typedef __bf16 bfloat16_t;
With a recent version of clang (I used 16.0.1) this results in warnings:
/usr/lib/clang/16/include/arm_neon.h:38:16: error: redefinition of typedef 'bfloat16_t' is a C11 feature [-Werror,-Wtypedef-redefinition]
Since `arm_bf16.h` is very likely supposed to be the one true place where
`bfloat16_t` is defined, I propose to delete the duplicate typedefs from the
generated `arm_neon.h` and `arm_sve.h`.
Reviewed By: sdesmalen, simonbutcher
Differential Revision: https://reviews.llvm.org/D148822
PR: 271047
MFC after: 1 month
[compiler-rt] Include system headers before optionally defining HWCAP macros
In https://reviews.llvm.org/D141285 the optional definitions of `HWCAP`
macros were moved to before their usage. However, they were also moved
to before the inclusion of system headers which can optionally define
them. If any of those system headers then actually defined any of the
`HWCAP` macros, it would result in a redefinition error.
Move the system header includes to just before the optional definitions,
to avoid this problem.
Reviewed By: ilinpv
Differential Revision: https://reviews.llvm.org/D148819
PR: 271047
MFC after: 1 month
Merge commit 962c306a11d0 from llvm-project (by Florian Hahn):
[LV] Don't consider pointer as uniform if it is also stored.
Update isVectorizedMemAccessUse to also check if the pointer is stored.
This prevents LV to incorrectly consider a pointer as uniform if it is
used as both pointer and stored by the same StoreInst.
Fixes#61396.
PR: 271992
Reported by: John F. Carr <jfc@mit.edu>
MFC after: 3 days
Certain internet service providers transmit vlan 0 priority tagged
EAPOL frames from the ONT towards the residential gateway. VID 0
should be ignored, and the frame processed according to the priority
set in the 802.1P bits and the encapsulated EtherType (i.e. EAPOL).
The pcap filter utilized by l2_packet is inadquate for this use case.
Here we modify the pcap filter to accept both unencapsulated and
encapsulated (with VLAN 0) EAPOL EtherTypes. This preserves the
original filter behavior while also matching on encapsulated EAPOL.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Reviewed by: cy
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D40442
Two files used to obtain time from reference clocks did not include
ntp_types.h resulting in an undefined NONEMPTY_TRANSLATION_UNIT.
Fixes: e6bfd18d21
MFC after: 3 days
X-MFC-with: e6bfd18d21
Important changes (relevant to FreeBSD):
#1814 Do not account for NULL terminator when comparing with "TRAILER!!!"
#1818 Add ability to produce multi-frame zstd archives
#1860 Make single bit bitfields unsigned to avoid clang 16 warning
#1869 Fix FreeBSD builds with WARNS=6
Obtained from: libarchive
Libarchive commit: 1f3c62ebf4d492ac21d3099b3b064993100dd997
Make struct pfsync_state contents configurable by sending out new
versions of the structure in separate subheader actions. Both old and
new version of struct pfsync_state can be understood, so replication of
states from a system running an older kernel is possible. The version
being sent out is configured using ifconfig pfsync0 … version XXXX. The
version is an user-friendly string - 1301 stands for FreeBSD 13.1 (I
have checked synchronization against a host running 13.1), 1400 stands
for 14.0.
A host running an older kernel will just ignore the messages and count
them as "packets discarded for bad action".
Reviewed by: kp
Sponsored by: InnoGames GmbH
Differential Revision: https://reviews.freebsd.org/D39392
Merge commit 069ecd0c6e2c from llvm-project (by Fangrui Song):
[ARM] Check target feature support for __builtin_arm_crc*
`__builtin_arm_crc*` requires the target feature crc which is available on armv8
and above. Calling the fuctions for armv7 leads to a SelectionDAG crash.
```
% clang -c --target=armv7-unknown-linux-gnueabi -c a.c
fatal error: error in backend: Cannot select: intrinsic %llvm.arm.crc32b
PLEASE submit a bug report to ...
```
Add `TARGET_BUILTIN` and define required features for these builtins to
report an error in `CodeGenFunction::checkTargetFeatures`. The problem is quite widespread.
I will add `TARGET_BUILTIN` for more builtins later.
Fix https://github.com/llvm/llvm-project/issues/57802
Differential Revision: https://reviews.llvm.org/D134127
Merge commit b2d7a0dcf1ff from llvm-project (by Fangrui Song):
[AArch64] Check target feature support for __builtin_arm_crc*
This is the AArch64 counterpart of D134127.
Daniel Kiss will change more `BUILTIN` to `TARGET_BUILTIN`.
Fix#57802
Note that programs attempting to use ARM/AArch64 CRC intrinsics, when
they are not supported by the targeted CPU, will still receive a regular
compilation error (instead of a fatal backend error) similar to:
7zCrc.c:4:10: error: '__builtin_arm_crc32b' needs target feature crc
return __builtin_arm_crc32b(a, b);
^
Reported by: Alastair Hogge <agh@riseup.net>
PR: 271624
MFC after: 3 days
Merge commit 0e7971154ecb from llvm-project (by Christopher Di Bella):
[libcxx][NFC] utilises compiler builtins for unary transform type-traits
Depends on D116203
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D131732
Clang 16 got new builtins that are equivalent to hand-written parts of
<type_traits>. When building world with the devel/llvm16 package
installed and CROSS_TOOLCHAIN=llvm16 set, this would lead to -Werror
warnings about those builtins being overridden.
Reported by: emaste
MFC after: 3 days
As of OpenSSL 1.1 SSL_library_init() and SSL_load_error_strings() are
deprecated. There are replacement initialization functions but they do
not need to be called: "As of version 1.1.0 OpenSSL will automatically
allocate all resources that it needs so no explicit initialisation is
required."
Wrap both calls in an OPENSSL_VERSION_NUMBER block.
Upstream pull request submitted at
https://github.com/openbsm/openbsm/pull/82
PR: 271615
Reviewed by: ngie
Event: Kitchener-Waterloo Hackathon 202305
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40273
As of 9fb6718d1b / __FreeBSD_version 1400089 stoppcbs is a pointer to
the pcbs array. Dereference stoppcbs on sufficiently new kernels.
Reviewed by: markj (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39939
This update removes printing of a leading zero in scientific or
engineering output modes (which are an extended feature of this
implementation).
(cherry-picked from commit 8b83ef067441f6d3a4a55e92d1738724954a057c)
MFC after: 2 weeks
> The SSL_library_init() and OpenSSL_add_ssl_algorithms() functions were
> deprecated in OpenSSL 1.1.0 by OPENSSL_init_ssl().
and
> The ERR_load_crypto_strings(), SSL_load_error_strings(), and
> ERR_free_strings() functions were deprecated in OpenSSL 1.1.0 by
> OPENSSL_init_crypto() and OPENSSL_init_ssl() and should not be used.
Reviewed by: ngie
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40065
Some highlights from NEWS:
** bio: fix CTAP2 canonical CBOR encoding in fido_bio_dev_enroll_*();
gh#480.
** New API calls:
- fido_dev_info_set;
- fido_dev_io_handle;
- fido_dev_new_with_info;
- fido_dev_open_with_info.
** Documentation and reliability fixes.
** Support for TPM 2.0 attestation of COSE_ES256 credentials.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Some highlights from NEWS:
** Added OpenSSL 3.0 compatibility.
** Removed OpenSSL 1.0 compatibility.
** Support for FIDO 2.1 "minPinLength" extension.
** Support for COSE_EDDSA, COSE_ES256, and COSE_RS1 attestation.
** Support for TPM 2.0 attestation.
** Support for device timeouts; see fido_dev_set_timeout().
** New API calls:
- es256_pk_from_EVP_PKEY;
- fido_cred_attstmt_len;
- fido_cred_attstmt_ptr;
- fido_cred_pin_minlen;
- fido_cred_set_attstmt;
- fido_cred_set_pin_minlen;
- fido_dev_set_pin_minlen_rpid;
- fido_dev_set_timeout;
- rs256_pk_from_EVP_PKEY.
** Reliability and portability fixes.
** Better handling of HID devices without identification strings; gh#381.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Merge commit 484e64f7e7b2 from llvm-project (by Roland McGrath):
[libc++] Use __is_convertible built-in when available
https://github.com/llvm/llvm-project/issues/62396 reports that
GCC 13 barfs on parsing <type_traits> because of the declarations
of `struct __is_convertible`. In GCC 13, `__is_convertible` is a
built-in, but `__is_convertible_to` is not. Clang has both, so
using either should be fine.
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D149313
Reported by: Mark Millard <marklmi@yahoo.com>
MFC after: 3 days
The fgetln loop will terminate with buf = NULL at EOF.
Reported by: GCC
Reviewed by: kp
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39947
This release that fixes an infinite loop bug in the (non-standard)
extended math library functions root() and cbrt(), fixes a bug with
BC_LINE_LENGTH=0, and adds the fib() function to the extended math
library to calculate Fibonacci numbers.
(cherry picked from commit 438a1101dc1f687928cdbe02cd7817a88a24f42f)
MFC after: 3 days
Merge commit a5e1a93ea10f from llvm-project (by Mariya Podchishchaeva):
[clang] Fix crash when handling nested immediate invocations
Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}
channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.
This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.
Fixes https://github.com/llvm/llvm-project/issues/58207
Reviewed By: aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D146234
PR: 269489
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by various declarations in libarchive:
contrib/libarchive/libarchive/archive_write_set_format_7zip.c:1541:13: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
file->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5127:15: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5213:14: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->dir = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:5214:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7149:18: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
isoent->virtual = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7435:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.detect_magic = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7495:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.making = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7496:26: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7702:28: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
iso9660->zisofs.allzero = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7871:25: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->header_passed = 1;
^ ~
contrib/libarchive/libarchive/archive_write_set_format_iso9660.c:7894:24: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
zisofs->initialized = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the fields as booleans, so make them unsigned.
This has also been sent upstream.
MFC after: 3 days
Clang 16 introduced a warning about single bit bitfields in structs,
which is triggered by a declaration in bsnmp's snmpd.h:
contrib/bsnmp/snmpd/trans_lsock.c:271:21: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
peer->input.stream = 1;
^ ~
Signed one-bit bitfields can only have values -1 and 0, but the intent
here is to use the field as a boolean, so make it unsigned.
MFC after: 3 days
The packet pointer (called packet) will remain uninitialized when
pcap_next_ex() returns an error. This occurs when the wlan
interface is shut down using ifconfig destroy. Adding a NULL
assignment to packet duplicates what pcap_next() does.
The reason we use pcap_next_ex() in this instance is because with
pacp_next() when we receive a null pointer if there was an error
or if no packets were read. With pcap_next_ex() we can differentiate
between an error and legitimately no packets were received.
PR: 270649
Reported by: Robert Morris <rtm@lcs.mit.edu>
Fixes: 6e5d01124f
MFC after: 3 days
Changes: https://github.com/eggert/tz/blob/2023c/NEWS
The tzdata 2023c release reverts all changes made in 2023b other than
commentary, as that appears to be the best of a bad set of short-notice
choices for modeling this week's daylight saving chaos in Lebanon.
MFC after: insta-MFC
Summary of changes:
- postpone mtu size assignment during load to avoid race condition
- refactor some of the debug prints
- add request reset handler
- refactor flush scheduler to increase efficiency and avoid racing
- put correct vlan_tag for UD traffic with PFC
- suspend QP before going to ERROR state to avoid CQP timout
- fix arithmetic error on irdma_debug_bugf
- allow debug flag to be settable during driver load
- introduce meaningful default values for DCQCN algorithm
- interrupt naming convention improvements
- skip unsignaled completions in poll_cmpl
Signed-off-by: Bartosz Sobczak bartosz.sobczak@intel.com
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: hselasky@
MFC after: 1 week
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D39173
This reverts the state to our old supplicant logic setting or clearing
IFF_UP if needed. In addition this adds logging for the cases in which
we do (not) change the interface state.
Depending on testing this seems to help bringing WiFi up or not log
any needed changes (which would be the expected wpa_supplicant logic
now). People should look out for ``(changed)`` log entries (at least
if debugging the issue; this way we will at least have data points).
There is a hypothesis still pondered that the entire IFF_UP toggling
only exploits a race in net80211 (see further discssussions for more
debugging and alternative solutions see D38508 and D38753).
That may also explain why the changes to the rc startup script [1]
only helped partially for some people to no longer see the
continuous CTRL-EVENT-SCAN-FAILED.
It is highly likely that we will want further changes and until
we know for sure that people are seeing ''(changed)'' events
this should stay local. Should we need to upstream this we'll
likely need #ifdef __FreeBSD__ around this code.
[1] 5fcdc19a81 and
d06d7eb091
Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: cy, enweiwu (earlier)
Differential Revision: https://reviews.freebsd.org/D38807
Although this code is in contrib/ there is no active upstream.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36047
- In the msgctl tests, there is no point in sleeping after a fork().
Just block immediately in wait().
- In non-blocking send/recv tests, just wait for the child to exit once
it's reached a message limit. If a bug prevents the child from
exiting promptly, the test will time out.
MFC after: 1 week
This version contains a fix for an issue that can affect complex
bc scripts that use multiple read() functions that receive input from
an interactive user. The same value could be returned multiple times.
MFC after: 2 weeks
Most ATM support was removed prior to FreeBSD 12. The netgraph support
was kept as it was less intrusive, but it is presumed to be unused.
Reviewed by: manu
Relnotes: yes
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D38879
When the kernel is built without capability mode support, or when
using an emulator like qemu-user-static that does not translate
system calls, these calls will return a negative number and set
the errno to ENOSYS. However, this error does not indicate a
real programming or runtime error and is generally ignored by
base system applications built with capability mode sandboxing.
Match this behavior by making xz(1) to ignore ENOSYS errors
when calling capability mode system calls too.
PR: 269185
Reported by: Dan Kotowski
MFC after: 2 days
This version adds a command to dc to query whether extended registers
are enabled or not.
(cherry picked from commit 61e1a12bb6c3bfdb0a4e499c88e8eaa2b548e427)
Note that this enables the backtracking extension, which we had previously left disabled.
PR: 244149, 269425
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D38421
Currently LLVM is more or less set up to use ELFv2, but it still defaults to
ELFv1 in some places. This causes lld to generate broken binaries when used
with LTO.
PR: 269455
Approved by: dim
MFC after: 3 days
In the past, we modified pcap/pcap.h to include the system net/bpf.h
rather than libpcap's own pcap/bpf.h. However, starting around 1.10.2,
libpcap requires a few extern functions defined in pcap/bpf.h to build.
Simply reverting that local change and pulling in pcap/bpf.h is not a
solution, because some ports with '#include <pcap.h>' such as mail/spamd
and net/xprobe require the system net/bpf.h to be pulled in. To
accommodate both requirements, make pcap/bpf.h a wrapper around the
system net/bpf.h, but retain the extern function definitions. This is
in preparation for libpcap 1.10.3.
Approved by: cy, philip, emaste, delphij (earlier revision)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38575
This function has been around since 4.4BSD but was dropped upstream in 2020. This went unnoticed when tzcode was updated. Bring it back, but prepare for removing it before 14.0 is released.
PR: 269445
MFC after: 3 days
Reported by: val@packett.cool
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38445
GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays. This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources). Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.
A similar change to this commit (albeit reworked due to upstream
changes) has been merged to libc++ in commit
26068c6e60324ed866a1ca2afb5cb5eb0aaf015b.
In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/ordering.h:13,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/common_comparison_category.h:12,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/tuple:168,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
from /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:36:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits: In instantiation of 'struct std::__1::__decay<llvm::CHIArg&, true>':
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1591:89: required from 'struct std::__1::decay<llvm::CHIArg&&>'
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__utility/pair.h:132:16: required by substitution of 'template<class _Tuple, typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> > constexpr std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::pair(_Tuple&&) [with _Tuple = llvm::CHIArg&&; typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> = <missing>]'
/usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:892:51: required from here
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1582:30: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' {aka 'llvm::CHIArg&'}
1582 | >::type type;
| ^~~~
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D36898
This reapplies commit c36de97088, which I
accidentally overwrote in the llvm 15 merge. (It turns out upstream did
not merge this to their 15.x branch.)
MFC after: 2 weeks
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-15-init-17826-g1f8ae9d7e7e4, the last commit before
the upstream release/16.x branch was created.
PR: 265425
MFC after: 2 weeks
Merge commit '755d9301ca89f02956fd17858b9d4d821ab5c972' from the
vendor branch. This updates us from lua 5.4.2 to 5.4.4.
In addition, it switches around how we flavor liblua for the boot loader
and flua. This is done to reduce diffs with upstream and make it easier
to import new versions (the current method has too many conflicts to
resolve by hand): we include luaconf.local.h from luaconf.h (the only
change to this file is now that #include at the end). We then define
what we need to: for flua (which does very little) and one for stand
(which creates the new FLOAT type out of int64).
Sponsored by: Netflix
This is not exhaustive - DWARF 5 has some new enumeration types not
implemented here - but I think I caught all the ones that are extended
in DWARF 5, plus the new compilation unit type (DW_UT_*), needed when
parsing .debug_info headers.
These were useful when extending libdwarf/ctfconvert/readelf to handle
DWARF generated by gcc 12, which is version 5 by default.
Reviewed by: emaste
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38273
Current content of the irdma(4) driver consists only of code that is
compilable on current 14-CURRENT branch which makes it impossible to
merge into stable/13 branch because of missing dependencies in the ofed
tree.
This patch adds missing code that allows for merging into stable branch.
Once it is there, code relating only to version 14 or higher should be
removed.
Signed-off-by: Eric Joyner <erj@FreeBSD.org>
Reviewed by: erj@
MFC after: 1 day
Sponsored by: Intel Corporation
Differential Revision: https://reviews.freebsd.org/D38170
This update contains only documentation changes (new main repository
URL and changed mail address of the program author) and changes to
the build system that do not affect the FreeBSD base system build.
MFC after: 3 days
A few have been added, a couple removed.
Reviewed by: jrtc27, imp, emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38175
