While we're here, enable the feature in the places we detect ACPI. This
lets us side-step the existing issues and provide a path forward for
folks upgrading from previous releases that haven't updated their ESP
yet.
Let's also fix core.setACPI: the hint already indicates that the
user's disabled it more consistently than loader.acpi_disabled_by_user.
Even more, the latter is wrong because we set it by default if we did
not detect ACPI. The ACPI hint remains even when we're setting defaults
because ACPI loaded into the kernel will make some noise if it's not
hinted off, even when we didn't detect it.
imp notes that this will result in some relatively harmless noise on
platforms that don't support ACPI but aren't using the UEFI loader, as
we would enable the ACPI module for loading on them and then loader
would not be able to find it. These are non-fatal, but should probably
be fixed by just declaring support for EARLY_ACPI in those loaders since
we know they won't have ACPI early on -- punting on this for the time
being, though, in favor of providing a safer upgrade path sooner.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42727
liblua now provides a loader.has_feature() function to probe the loader
binary for features advertised. name => desc mappings are provided in
loader.features to get a list of all of the features loader *can*
support. core.hasFeature is provided as a shim to loader.has_feature
so that individual consumers don't need to think about the logic of the
loader module not providing has_feature; we know that means the feature
isn't enabled.
The first consumer of this will be EARLY_ACPI to advertise that the
loader binary probes for ACPI presence before the interpreter has
started, so that we know whether we can trust the presence of acpi.rsdp
as relatively authoritative. In general, it's intended to be used to
avoid breaking new scripts on older loaders within reason.
This will be used in lua as `core.hasFeature("EARLY_ACPI")`, while the
C bits of loader will `feature_enable(FEATURE_EARLY_ACPI)`.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D42695
[Clang] Do not change the type of captured vars when checking lambda constraints
When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.
In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.
Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.
There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.
Fixes#61267
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D158433
Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):
[Clang] Add captures to the instantiation scope of lambda call operators
Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.
This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.
`*this` (like all captures) only become `const`
after the parameter list.
However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).
There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.
Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.
Fixes#65067Fixes#63675
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D159126
This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
instantiated in this scope"), function findInstantiationOf' error when
building databases/mongodb44.
PR: 273753
MFC after: 1 month
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-17-init-19304-gd0b54bb50e51, the
last commit before the upstream release/17.x branch was created.
PR: 273753
MFC after: 1 month
And neither are most libcasper services' functions, because internally
they all use cap_xfer_nvlist. cap_xfer_nvlist sends and then receives
data over a unix domain socket and associated with the cap_channel_t
argument. So absent synchronization, two threads may not use the same
cap_channel_t argument or they risk receiving the other's reply.
MFC after: 2 weeks
Sponsored by: Axcient
Reviewed by: oshogbo
Differential Revision: https://reviews.freebsd.org/D42928
#15539687e4d7f9 Extend import_progress kstat with a notes field
#15544c7b611926 Allow block cloning across encrypted datasets
#15553adcea23cb ZIO: Add overflow checks for linear buffers
#155935f2700eee zpool: flush output before sleeping
#156093e4bef52b Only provide execvpe(3) when needed
#15610735ba3a7b Use uint64_t instead of u_int64_t
#15612bcd83ccd2 ZIL: Remove TX_CLONE_RANGE replay for ZVOLs
#1561755b764e06 ZIL: Do not clone blocks from the future
#15623727497ccd module/icp/asm-arm/sha2: enable non-SIMD asm kernels
on armv5/6
#156259743d0963 BRT: Limit brt_vdev_dump() to only one vdev
#15629f9765b182 zdb: Dump encrypted write and clone ZIL records
#156342aa3a482a ZIL: Remove 128K into 2x68K LWB split optimization
#1563911656234b FreeBSD: Ensure that zfs_getattr() initializes the
va_rdev field
#156474836d293c zfs_refcount_remove: explictly ignore returns
#15649f0cb6482e setproctitle: fix ununitialised variable
#15650450f2d0b0 import: ignore return on hostid lookups
Obtained from: OpenZFS
OpenZFS commit: 450f2d0b08
This makes code cleaner, plus fixes such nonsense as humanized JSON
and XML, making all numbers raw without quotes, spaces, suffixes, etc.
MFC after: 2 weeks
This patch implements the interrupt blocking VM capability on AMD
CPUs. Implementing this capability allows the GDB stub to single-step
a virtual machine without landing inside interrupt handlers.
Reviewed by: jhb, corvink
Sponsored by: Google, Inc. (GSoC 2022)
Differential Revision: https://reviews.freebsd.org/D42299
This patch implements single-stepping for AMD CPUs using the RFLAGS.TF
single-stepping mechanism. The GDB stub requests single-stepping
using the VM_CAP_RFLAGS_TF capability. Setting this capability will
set the RFLAGS.TF bit on the selected vCPU, activate DB exception
intercepts, and activate POPF/PUSH instruction intercepts. The
resulting DB exception is then caught by the IDT_DB vmexit handler and
bounced to userland where it is processed by the GDB stub. This patch
also makes sure that the value of the TF bit is correctly updated and
that it is not erroneously propagated into memory. Stepping over PUSHF
will cause the vm_handle_db function to correct the pushed RFLAGS
value and stepping over POPF will update the shadowed TF bit copy.
Reviewed by: jhb
Sponsored by: Google, Inc. (GSoC 2022)
Differential Revision: https://reviews.freebsd.org/D42296
This patch adds support for software breakpoint vmexits on AMD SVM.
It implements the VM_CAP_BPT_EXIT used to enable software breakpoints.
When enabled, breakpoint vmexits are passed to userspace where they
are handled by the GDB stub.
Reviewed by: jhb
Sponsored by: Google, Inc. (GSoC 2022)
Differential Revision: https://reviews.freebsd.org/D42295
This patch refactors AMD SVM event reflection to allow events to be
propagated to userland, rather than always reflected into the guest.
This is necessary to implement some capabilities that request VMEXITs
when a specific exception occurs (e.g. VM_CAP_BPT_EXIT).
Reviewed by: jhb
Sponsored by: Google, Inc. (GSoC 2022)
Differential Revision: https://reviews.freebsd.org/D42405
After d2ef52ef3d the tcp_hpts_init() function can be called multiple
times on a tcpcb if it is switched there and back between two TCP stacks.
First, this makes existing assertion in tcp_hpts_init() incorrect. Second,
it creates possibility to change a randomly set t_hpts_cpu to a different
random value, while a tcpcb is already in the HPTS wheel, triggering other
assertions later in tcp_hptsi().
The best approach here would be to work on the stacks to really clear a
tcpcb out of HPTS wheel in tfb_tcp_fb_fini, draining the IHPTS_MOVING
state. But that's pretty intrusive change, so let's just get back to the
old logic (pre d2ef52ef3d) where t_hpts_cpu was set to a random value
only once in a CPU lifetime and a newly switched stack inherits t_hpts_cpu
from the previous stack.
Reviewed by: rrs, tuexen
Differential Revision: https://reviews.freebsd.org/D42946
Reported-by: syzbot+fab29fe1ab089c52998d@syzkaller.appspotmail.com
Reported-by: syzbot+ca5f2aa0fda15dcfe6d7@syzkaller.appspotmail.com
Fixes: 2b3a77467d
This change seems to break some drivers such as the mlx5*(4) drivers.
As kib@ says:
> According to the 'official' Linux kernel documentation, the GFP_KERNEL
> flag implies sleepable context.
It was introduced while working on the new vt(4)/DRM integration [1].
During this work, doing sleepable allocations broke vt(4) and the DRM
drivers. However, I made further improvements and some locking-related
fixed to the new integration without revisiting the need for it.
After more testing, the improvements to the integration mentionned above
seems to make the change to `GFP_KERNEL` unneeded now. I can thus
revert it to restore expectations of other drivers.
This reverts commit 14dcd40983.
[1] https://github.com/freebsd/drm-kmod/pull/243
Reviewed by: kib
Approved by: kib
Differential Revision: https://reviews.freebsd.org/D42962
There's no need to use echo -n here. A single echo will do nicely.
This fixes the post-buildworld output on a macos build, where echo -n
is implemented like System V instead of BSD (so you get two lines
first one starting with -n).
Sponsored by: Netflix
Reviewed by: jrtc27, emaste
Differential Revision: https://reviews.freebsd.org/D42869
On MacOS, we bootstrap sort. Since ALTMON_* are not defined there, the
build blows up. Since we don't need this feature for the FreeBSD build
process, and since we won't use it unless we actually install the NL
files that have this data in it, just #ifdef it out for now. In the
extremely unlikely event that the FreeBSD bootstrap/build process grows
this dependency, we can evaluate the best solution then (which most
likely is going to be not depend on the local's month names).
Fixes: 3d44dce90a (MacOS builds and github CI)
Sponsored by: Netflix
Reviewed by: jrtc27, jlduran@gmail.com, markj
Differential Revision: https://reviews.freebsd.org/D42868
From NetBSD's utils.c 1.5 importing importing BSDI change, with light
formatting changes:
Author: cgd <cgd@NetBSD.org>
Date: Wed Feb 26 14:40:51 1997 +0000
Patch from BSDI (via Keith Bostic):
>NFS doesn't support chflags; ignore errors unless there's reason
>to believe we're losing bits. (Note, this still won't be right
>if the server supports flags and we were trying to *remove* flags
>on a file that we copied, i.e., that we didn't create.)
CVS Info: utils.c 1.6
Obtained from: NetBSD
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42674
Add -N to supress copying of file flags when -p is specified (explicitly
or implicitly). Often times we don't care about the flags or wish to be
able to copy to NFS, and this comes in handy for that. FreeBSD's and
NetBSD's cp are somewhat different, so I had to reimplement all but one
of the patch hunks...
Obtained from: NetBSD (cp.1 1.25, cp.c 1.37, utils.c 1.28 by elad)
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D42673
Just silencing a warning. Its totally fine for a hostid to not be there.
Reported-by: Coverity (CID-1573336)
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes#15650
Reported-by: Coverity (CID-1573333)
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes#15649
Coverity noticed that sometimes we ignore the return, and sometimes we
don't. Its not wrong, and I like consistent style, so here we are.
Reported-by: Coverity (CID-1564584)
Reported-by: Coverity (CID-1564585)
Reported-by: Coverity (CID-1564586)
Reported-by: Coverity (CID-1564587)
Reported-by: Coverity (CID-1564588)
Reviewed-by: Alexander Motin <mav@FreeBSD.org>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Rob Norris <robn@despairlabs.com>
Closes#15647
Otherwise the field is left uninitialized, leading to a possible kernel
memory disclosure to userspace or to the network. Use the same
initialization value we use in zfsctl_common_getattr().
Reported-by: KMSAN
Sponsored-by: The FreeBSD Foundation
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ed Maste <emaste@FreeBSD.org>
Signed-off-by: Mark Johnston <markj@FreeBSD.org>
Closes#15639
Don't let PRR pass up on the opportunity of clocking
out packets on arrival of ACKs - by pulling sends
forward by about half a packet. Prevents unexpectedly
long runs of incoming ACKs without eliciting a
packet transmission.
MFC after: 1 week
Reviewed By: #transport, tuexen
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42918
Refactoring to perform the batch processing of
log messaged in two phases. First cycling through a limited
number of collected packets, and only thereafter freeing
the processed packets. This prevents any chance of calling
free while in a critical / spinlocked section.
Reviewed By: tuexen
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D42949
Ensure that the vnet list cannot be modified while we're running through
it.
Reviewed by: mjg (previous version), zlei (previous version)
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D42927
Some Raspberry Pi pass smsc95xx.macaddr=XX:XX:XX:XX:XX:XX as bootargs.
Use this if no ethernet address is found in an EEPROM.
As last resort fall back to ether_gen_addr() instead of random MAC.
PR: 274092
Reported by: Patrick M. Hausen (via ML)
Reviewed by: imp, karels, zlei
Tested by: Patrick M. Hausen
Approved by: karels
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D42463
Without this patch on pool of 60 vdevs with ZFS_DEBUG enabled clone
takes much more time than copy, while heavily trashing dbgmsg for
no good reason, repeatedly dumping all vdevs BRTs again and again,
even unmodified ones.
I am generally not sure this dumping is not excessive, but decided
to keep it for now, just restricting its scope to more reasonable.
Reviewed-by: Kay Pedersen <mail@mkwg.de>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#15625
After removing filter functionality, the naming doesn't clearly
represent what the function does, so try to address this. Include some
code clarity and style improvements.
Create a common version in subr_busdma_bounce.c, used by most
implementations. powerpc still needs its own version of the function,
due to its dmat->iommu == NULL check.
No functional change intended.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42896
Without filter functions, we do not need to keep track of tag ancestry.
All inheritance of the parent tag's parameters occurs when creating the
new child tag.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42895
Address filter functions are unused, unsupported, and now rejected.
Simplify some busdma code by removing filter functionality completely.
Note that the chains of parent tags become useless, and will be cleaned
up in the next commit.
No functional change intended.
Reviewed by: jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42894
A deprecation notice was added to the bus_dma(9) man page by scottl@ in
September 2020 discouraging the use of filter functions. I've performed
an attentive check of all callers in the tree and everything that exists
today passes NULL for both filtfunc and filtarg. Thus, we should start
returning EINVAL if these arguments are non-NULL to prevent new usages
from popping up. Update the man page to be more clear about this.
The deprecation notice is present since at least 13.0-RELEASE, so this
is the appropriate step for the lifetime of 15, without actually
breaking the driver API. Stable branches will emit a warning instead.
This change enables the removal of a fair amount of unused complexity
across the various busdma implementations.
Reviewed by: jhb
MFC after: never
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D42852
To improve 128KB block write performance in case of multiple VDEVs
ZIL used to spit those writes into two 64KB ones. Unfortunately it
was found to cause LWB buffer overflow, trying to write maximum-
sizes 128KB TX_CLONE_RANGE record with 1022 block pointers into
68KB buffer, since unlike TX_WRITE ZIL code can't split it.
This is a minimally-invasive temporary block cloning fix until the
following more invasive prediction code refactoring.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Ameer Hamza <ahamza@ixsystems.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored by: iXsystems, Inc.
Closes#15634
Currently we just strip the .txz of the dist name (and add a status_
prefix) to get the shell variable name for its status, but this doesn't
give a valid result for dists like base-dbg, kernel-dbg and lib32-dbg,
or even kernel.KERNCONF (or, combining the two, kernel.KERNCONF-dbg). As
a result, four things go wrong for such dists:
1. If there is a dot and/or a dash in the name, writing to the variable
fails and spits an error out on stderr to the log
3. If there is a dot in the name before any dash, the syntax is always
invalid, reading the variable fails, spits an error out on stderr to
the log, the result is the empty string and that is interpreted as
being 0%
2. If there is a dash in the name before any dot, and there is a dist
whose name is the substring up to that first dash, and it has already
had its status written to, reading the variable instead reads that
dist's variable and so the status of that dist is displayed instead
3. If there is a dash in the name before any dot, and either there is
not a dist whose name is the substring up to that first dash or there
is such a dist but it has not already had its status written to,
reading the varaible instead results in the substring after the first
dash, including any additional string expansion syntax that follows
(i.e. ${status_kernel-dbg:--11}, the expression used to read the
variable, is interpreted as reading status_kernel with a default
value of "dbg:--11")
For example, in a default install with base, kernel, kernel-dbg and
lib32, the following sequence of displays happens:
1. base is In Progress, kernel is Pending, kernel-dbg is 0% (what shows
for the garbage input "dbg:--11") and lib32 is Pending
2. base is Passed, kernel is In Progress, kernel-dbg is In Progress
(since kernel has now had its status written to) and lib32 is
Pending
3. base is Passed, kernel is Passed, kernel-dbg is Passed (again, since
that is the status of kernel, despite that kernel-dbg is being
verified at this point) and lib32 is Pending
4. base is Passed, kernel is Passed, kernel-dbg is Passed and lib32 is
In Progress
Fix this with a crude encoding scheme. More special characters can
easily be added if needed in future.
Note that, prior to bsddialog being used (and thus for branches this is
MFC'ed to where dialog is still used), the same problem existed but
displayed slightly differently due to a combination of different default
values and different behaviour for unintended inputs.
Fixes: b70047d413 ("Add generation of an installation manifest containing SHA256 checksums as ...")
MFC after: 1 week
