When knob is zero, intent is that no SIGSYS signals are delivered.
Comparing zero to zero does not test much, we should compare the count
of delivered SIGSYSs to zero.
Reviewed by: dchagin, imp
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44077
For safety, only include the interpreter's linker script. Note that the
simple loader doesn't have one, but it's not an error to copy a ELF
section that does not exist. No functional change, however.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44064
And upcoming change will need this set to be named this. Since it's only
used in the efi Makefile, and inside if ficl itself, the change should
be a nop.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44063
After the linker set cleanup in ldscripts, there's now only one place we
need to know the linkerset name, so go ahead and change the lua
interpreter augmentation linker set to be uniquely named.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44062
We don't need linker sets listed as sections. They are explicitly
included in the objcopy we use to create the .efi file. This practice
was added in 2002 by peter@ in a6d81d83a2 to make ia64 builds
self-hosted. However, it was added back to the objcopy in 2010 by rpaulo
in 8df7a05edd for i386 EFI support, though the ldscript file then
retained them needlessly. The gcc/binutils bug having been fixed in the
interim. We've not needed them since then, but the redundancy didn't
matter.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44061
Linker set sections are included by default. No need to do so
explicitly. These were bogusly copied from the efi ldscripts. They were
there due to a workaround introduced in 2002 by peter@ for a gcc
upgrade, but whatever bugs necessitated it were filed by 2010 when
rpaulo@ imported the i386 support (though they were copied even though
the objcopy retained them correctly, the gcc bug having been
fixed). They've never been needed.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44060
Move to the foo.ldconfig convention to match the rest of the boot
loader. No functional change intended.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44059
Share ldscript between the different ppc versions. There's two different
scripts since we build 32-bit binaries for all types of powerpc, but
have little endian and big endian variations that are different by only
two lines. Set the output format and include the rest.
Move to foo.ldscript as well.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44058
Make the pattern for ldscripts always be
arch/$MACHINE_ARCH/$MACHINE_ARCH.ldscript so we can add it from a
central Makefile. This also moves from ldscript.arch to arch.ldscript to
match the loader's new convention.
Sponsored by: Netflix
Reviewed by: tsoome, kevans
Differential Revision: https://reviews.freebsd.org/D44057
In the larger open source community, ld scripts are foo.ldscrpt rather
than ldscript.arch like we use here. This moves the EFI ldscripts.
Sponsored by: Netflix
Reviewed by: tsoome, kevans, emaste
Differential Revision: https://reviews.freebsd.org/D44056
This is a migitation to avoid sudden extreme jumps in
cwnd, as t_epoch can be very out of date after an RTO.
Per RFC9438, sec 4.8, t_epoch is to be reset whenever
cwnd grows beyond ssthresh (CC phase transitions from
slow start to congestion avoidance), to be fixed with
the upcoming cc_cubic changes.
MFC after: 3 days
Reviewed By: cc, #transport
Sponsored by: NetApp, Inc
Differential Revision: https://reviews.freebsd.org/D44023
Ensure that snd_fack holds a valid value when doing
the post_recovery CC processing, for preparation of
the cc_cubic update, so that local pipe calculations
can correctly refer to snd_fack during and after CC events.
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43957
Facilitate easier troubleshooting by enumerating
all congestion control signals. Typecast the
enum to int, when a congestion control module uses
private signals.
No external change.
Reviewed By: glebius, tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43838
Make sure the divident is at least one. While cwnd should
never be smaller than t_maxseg, this can happen during
Path MTU Discovery, or when TCP options are considered
in other parts of the stack.
PR: 276674
MFC after: 3 days
Reviewed By: tuexen, #transport
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D43797
We have the call to gfx_interp_ref to bring in the .o so that we get the
linker set item to add the language bindings at the right time. Where we
call it is not the right time... So the _ref name is better. Change it
before we have too many others like it.
Sponsored by: Netflix
Although a port addition is coded in a sequence where first all softc
information is fulfilled and only then it is attached to the lagg, we
still need a locking primitive to guarantee cache invalidation. Panic
observed in the wild shows that lacp_portreq() called via
lagg_port_ioctl(SIOCGLAGGPORT) immediately after port creation may see
lp->lp_psc as NULL and panic. In the core file we will see valid data
all around. A race via lagg_ioctl() wasn't observed but potentially
is possible.
Differential Revision: https://reviews.freebsd.org/D43501
The test needs to be performed in a new process that was forked with
RFCFDG flag. The will guarantee that the table will start to grow from 20
file descriptors, no matter what kyua(1) or a bare shell was doing before
executing this test. This should fix repetitive test runs from a shell
as well as failures with kyua(1) in some environments.
This reverts commit fa6a02f50e.
It makes the test less probable to fail, but it doesn't fix the
root issue - that on entry the parent process may have already
a large file descriptor table.
Despite still being in production the device appeared not able to use
memory above BUS_SPACE_MAXADDR_32BIT, and if your desktop has a lot of
memory there is a high chance driver would allocate inaccessible memory.
Submitted by: wulf
Reviewed by: mav
Move functions back to libc/gen sources; they are only versioned from
libc and not libsys.
Access libsys interposing slots using __libsys_interposing_slot()
instead of direct __libsys_interposing array dereference, which cannot
work from libc.
Reported by: glebius
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D44042
so that libc/libthr do not preempt libsys symbols, esp. errno-related.
The issue is, if libsys is linked with DT_BIND_NOW flag, and then loaded
as filter, rtld tries to relocate its PLT symbols immediately, not as
filter. There, during symbol lookup, rtld finds filtering symbols in
libc, and since libc is in loading filters mode, the resolution stops
there. The end result is that libsys links to libc.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D44027
If cnt == 0 we access element 0 unconditionally, which is out of bounds,
and then if that doesn't crash and happens to be 0 we will access
element - 1, also out of bounds, and then if that doesn't crash will add
1 to whatever junk is there and use that for the variable. On CHERI,
though, this does crash. This code is also overly complicated, with
unnecessary special cases and tracking more state than needed.
Rewrite it in a more general manner that doesn't need those special
cases and naturally works for cnt == 0.
Found by: CHERI
Reviewed by: imp
Fixes: 1285bcc833 ("Import Netflix's efibootmgr to help manage UEFI boot variables")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D44029
Some calls, e.g., action frames cause us to call through all the
way down to firmware from the RX path without any deferral in
net80211.
For LinuxKPI and iwlwifi this goes (with omissions) like this:
lkpi_napi_task -> linuxkpi_ieee80211_rx -> ieee80211_input_mimo ->
sta_input -> ht_recv_action_ba_addba_request ->
lkpi_ic_ampdu_rx_start -> iwl_mvm_mac_ampdu_action ->
iwl_trans_txq_send_hcmd. At that point we are waiting for an
interrupt from the firmware but given the lkpi_napi_task has not
finished (and may have more to dispatch based on budget and what
was received) we will not see the new interrupt/fw response.
With no answer from the firmware, the software timeout in the
driver kills the command and the firmware and issues a complete
restart.
Implement the deferred RX path in LinuxKPI for the moment.
At a later point we should carefully shift this into net80211.
This fixes the hangs for (*ic_ampdu_rx_start)() calls with iwlwifi.
MFC after: 3 days
PR: 276083
Reviewed by: cc
Differential Revision: https://reviews.freebsd.org/D43968
Use the macro "UART_CLASS()" for the newly created data set
'uart_class_set' as we do for other data sets.
This further hides the data set name.
Also add UART_CLASS for quicc, which was previously not done.
MFC after: 1 week
Improves: 949670f8f4 dev/uart: Use a linker set to find uart classes
Obtained from: jhb, 269e99ac86
Reviewed by: andrew
Differential Revision: https://reviews.freebsd.org/D43981
Enabling 11n for ath(4) so far was handled by a kernel option, which
was only enabled for certain kernel configurations.
In order to allow loading ath(4) as a module with 11n support on
all platforms, remove the kernel option and unconditionally enable
11n in ath(4).
Reported by: pkubaj
Discussed with: adrian in D43549.
Reviewed by: adrian, imp
Differential Revision: https://reviews.freebsd.org/D43964
Ideally we'd be able to use LDADD_foo here for all our various libs and
get the implicit dependencies, but rescue is a bit special. Historically
this was just used to pick up the "private" in the name automatically
(as far as I can tell), but now that _DP_pthread includes c we end up
pulling in a -lc from this (along with -lcompiler_rt and -lsys). This
results in -lc being before -lmd (and after, implictly, from the
compiler driver), which, for the specific situation here, results in
both libc.a's and libmd.a's md5c.o being included, giving duplicate
definitions of _libmd_MD5Init and other symbols. With LLD 16+ we
currently make that not an error for other reasons (which should
probably be fixed), but not for older versions, nor for BFD, and so the
build fails.
Fix all this by just using -lprivatezstd in place of LDADD_zstd, which
results in the exact same clang command line as we used to have prior to
adding c (and sys) to _DP_pthread when linking rescue. Note that bsdbox
already uses -lprivatezstd rather than LDADD_zstd.
This reverts commit 5fead429eb.
Reviewed by: imp
Fixes: 99ea675731 ("lib{c,sys}: move auxargs more firmly into libsys")
The goal of reserving firmware-assigned resources is to ensure that
"wildcard" resource allocation requests will not claim an address
range that is actually in use even if no attached driver is actively
using that range. However, the current approach can break in some
cases.
In particular, ACPI can enumerate devices behind PCI bridges that
don't show up in a normal PCI scan, but those device_t objects can end
up as direct children of acpi0. Reserving resources for those devices
directly from acpi0 ends up conflicting with later attempts to reserve
the PCI bridge windows.
As a workaround, defer reserving unclaimed resources until after the
initial probe and attach scan. Eventually this pass of reserving
unclaimed resources can be moved earlier, but it requires changes to
other drivers in the tree to permit enumerating devices and reserving
firmware-assigned resources in a depth-first traversal before
attaching devices whose drivers request wildcard allocations.
PR: 272507
Reported by: Justin Tocci <justin@tocci.org>
Reported by: john@feith.com, many others
Tested by: Oleg Sidorkin <osidorkin@gmail.com>, dch
All other architectures set NEW_PCIB in DEFAULTS, with arm being the one
remaining straggler that only sets it for GENERIC and TEGRA124.
ARMADA38X and ARMADAXP contain device pci but don't set NEW_PCIB,
however GENERIC claims to support them and as part of that NEW_PCIB
support was added to mv_pci, so these configs are most likely just
stale. Other than NOTES that just leaves ALPINE as the one kernel with
PCI support not covered by GENERIC, but al_pci is supported by arm64
which enables NEW_PCIB, and it's just a generic_pcie_fdt_driver with
some fixup code to deal with quirks so should support PCI_RES_BUS just
fine. Therefore it is believed that all in-tree kernel configs support
NEW_PCIB in reality, and so let's take a step towards removing all the
non-NEW_PCIB code by having it always-on everywhere.
Reviewed by: emaste, jhb, manu
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D43806
When BEARSSL is enabled, we pull in libsecureboot, which has EFI
dependencies which don't exist on powerpc. This needs to be detangled,
but until then mark it as broken.
Sponsored by: Netflix
