Fix a NULL dereference in _kadm5_s_init_context() when the client
sends a mangled realm message.
PR: 267912
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 3 days
Should the sender send a string without a terminating NUL, ensure that
the NUL terminates the string regardless.
And while at it only process the version string when bytes are returned.
PR: 267884
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D37471
Previously when using NO_ROOT we recorded a METALOG entry for the
pam.d/ftp hard link with a different file mode than the link target
pam.d/ftpd, which is not permitted.
This change is similar to 1dbb9994d4 for .profile
Sponsored by: The FreeBSD Foundation
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
Previoulsy when using NO_ROOT we recorded METALOG entries for dwatch
hard links with different file modes than their link targets, which is
not permitted.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37477
Previously when using NO_ROOT we recorded a METALOG entry for the
/.profile hard link with a different mode than the link target, which is
not permitted.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37476
x2apic accesses are handled by a wrmsr exit. This handler is called in a
critical section. So, we can't lock a mtx in the icr_low handler.
Reported by: kp, pho
Tested by: kp, pho
Approved by: manu (mentor)
Fixes: c0f35dbf19 vmm: Use a cpuset_t for vCPUs waiting for STARTUP IPIs.
MFC after: 1 week
MFC with: c0f35dbf19
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37452
GCC warns about the non-literal format string passed to strftime(). A
warning here seems a bit odd as strftime() does not take varargs so
there is not a risk of missing args.
I think this was probably just a typo. initifstat() continues around
a similar loop if the mib data fails to fetch, and fetch_ifstat() was
already using a FOREACH_SAFE loop here so expected to keep going.
Calling clearifstat() from the fetch routine also seems wrong, and the
sort_interface_list() call triggered by the existing needsort = 1 will
itself set needclear to trigger a future clearifstat().
Reported by: GCC 12 -Wuse-after-free
Differential Revision: https://reviews.freebsd.org/D36823
f808c43ad9 introduced a FreeBSD specific
behaviour to wait for firmware load completion before returning from
loading the driver. This does no longer allow iwl_drv_stop to detect
that startup has completed and it will wait indefinitely for a
completion event that will not happen.
We could change the complete() call to a complete_all() but to avoid
confusion, future side effects, and for simplicity daisy-chain two
complete events in FreeBSD.
PR: 267869
Reported by: Peter Much (pmc citylink.dinoex.sub.org)
Tested by: Peter Much (pmc citylink.dinoex.sub.org)
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Saves on work in a common case of checking both directions.
Note further work in the area is impending to elide these in the common
case to begin with.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36485
As PF now also supports dummynet but can not configure it on its own,
the service which configures pipes, queues and schedulers is needed.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D37451
Running "dnctl" vs "/sbin/dnctl" gave different results, because we
looked at the entire argv[0] string, rather than the basename.
Reviewed by: kp
Differential Revision: https://reviews.freebsd.org/D37431
Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold
which specifies a temperature above which a system should transition
to the S3 standby state.
On FreeBSD, this is more useful than _HOT, which specifies the S4
transition threshold temperature (since FreeBSD does not generally
support the S4 state), or, in many cases, _CRT, since after
transitioning to S3 the system can cool and then be resumed.
Reviewed by: jhb, bcr (manpages)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D35980
A small reduction in build infrastructure complexity; when we had both
Clang and GCC in the tree it was useful to have both built, and choose
one or the other to install as /usr/bin/cc. Now only Clang is in the
tree, and there is no point in building and installing base Clang but
not providing it as cc (and c++, cpp).
Reviewed by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37075
Now that all ACPI tables are build by basl, basl can dynamically
calculate the offset for each table.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37002
Building the RSDP table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37001
Building the RSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37000
Building the XSDT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36999
Building the FADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36998
Building the MADT table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36997
Building the HPET table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36996
Building the MCFG table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36995
The common style for build an ACPI table will be:
1. basl_table_create
2. basl_table_append_header
3. setup an ACPI_TABLE_* struct
4. basl_table_append_bytes (without header)
Add a helper for the last step.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37406
The code will be more readable if we use struct definitions from ACPI-CA
to build ACPI tables. We can fill out the struct and append it to the
basl_table by using basl_table_append_bytes. After that, we have to
declare which checksums, length and pointers should be patched by basl.
That's done by the add_* functions.
Reviewed by: jhb, markj
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37405
Building the FACS table by basl will allow it to be loaded by qemu's
ACPI table loader in the future.
Reviewed by: jhb, markj (older version)
Approved by: manu (mentor)
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D36994
When a vcpu sees that a rendezvous is in progress, it exits and tries to
handle the rendezvous. The vcpu doesn't check if it's part of the
rendezvous or not. If the vcpu isn't part of the rendezvous, the
rendezvous could be done before it reaches the assertion. This will
cause a panic.
The assertion isn't needed at all because vm_handle_rendezvous properly
handles a spurious rendezvous. So, we can just remove it.
PR: 267779
Reviewed by: jhb, markj
Tested by: bz
Approved by: manu (mentor)
MFC after: 1 week
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D37417
32-bit powerpc doesn't have a fuword64, so only use it on powerpc64.
This could also be done elsewhere that splits 32-bit and 64-bit
accesses, but adding ifdefs everywhere would just clutter up the source
for little benefit. This is the only usage of fuword64 directly; other
archs have a dtrace_fuword64_nocheck(), but powerpc does not, and I
don't see a need to add it currently.
MFC after: 1 week
Commit 5e6a2d6eb2 moved libc++ from /usr/lib to /lib, so we no longer
have an interval during boot when it is not available (before /usr is
mounted). We no longer need to force devd to be statically linked.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37409