Change POOL_NEXT_SIZE define value from 0 to BIT(30), since this define
is used to request the available maximum sized flow table, and zero doesn't
make sense for it, whereas many places in the driver use zero explicitly
expecting the smallest table size possible but instead due to this
define they end up allocating the biggest table size unawarely.
Sponsored by: NVidia networking
Align the code of fdb steering with flow steering core
and add missing parts in namespace initialization and
in prio logic
PR: 281714
Sponsored by: NVidia networking
Register the PCINT handler using the nmi_{register, remove}_handler
interfaces (introduced in D46421) in preparation for hwt(4)'s
Intel Processor Trace backend. No functional change intended.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47989
This patch adds several routines that track and expose information
about various XSAVE-related features. More specifically, it adds the
ability to check whether a given XFEATURE is supported and which XSAVE
extensions are supported. Furthermore, it adds several routines for
calculating the size and offsets within a save area given a XSAVE
feature bitmap.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47394
This patch adds definitions for Intel PT-related MSRs and
several PT feature bits.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D46419
This patch refactors the Performance Counter interrupt setup code to
allow sharing the interrupt line between multiple drivers.
More specifically, Performance Counter interrupts are used by both
hwpmc(4) and hwt(4)'s upcoming Intel Processor Trace backend.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D46420
This refactor aims to add the ability to share performance counter
interrupts by refactoring the kernel-mode NMI handler. The handler now
allows multiple drivers to service the same interrupt (e.g. hwpmc(4)
and hwt(4)'s Intel Processor Trace backend).
Reviewed by: kib, avg
Differential Revision: https://reviews.freebsd.org/D46421
Note in the manpage that the 2024 edition finally added ppoll(), and
also add the appropriate declarations for the correct versions of
_POSIX_C_SOURCE (via __POSIX_VISIBLE).
Differential Revision: https://reviews.freebsd.org/D48043
I added a third value for kern.logsigexit to mean 'auto' as an abundance
of caution, but I don't know how much it matters -- that can be easily
consolidated back to boolean-ish.
This is primarily targeted towards people running test suites under CI
(e.g. buildbot, jenkins). Oftentimes tests entail segfaults that are
expected, and logs get spammed -- this can be particularly high volume
depending on the application. Per-process control of this behavior is
desirable because they may still want to be logging legitimate
segfaults, so the system-wide atomic bomb kern.logsigexit=0 is not a
great option.
This adds a process flag to disable it, controllable via
procctl(2)/proccontrol(1); the latter knows it as "sigexitlog" due to
its length, but it's referred to almost everywhere else as
"sigexit_log."
Reviewed by: kib (earlier version), pstef
Differential Revision: https://reviews.freebsd.org/D21903
Note in the manpage that the 2024 edition finally added ppoll(), and
also add the appropriate declarations for the correct versions of
_POSIX_C_SOURCE.
Differential Revision: https://reviews.freebsd.org/D48043
* add a register value for the R92C_FPGA0_POWER_SAVE register
* add the field names and mask
* add a mask for the 40MHz upper/lower bits in R92C_RMRR; I think
I need to debug and overhaul the 20/40MHz config path to get 40MHz
working right.
Local testing:
* rtl8188eu, sta mode
* rtl8192cu, sta mode
* RX frames with short-GI can be either HT or VHT
* Add placeholders for RX VHT rate, PHY type, etc
Differential Revision: https://reviews.freebsd.org/D47902
Summary: Export the kernel API pgrp_calc_jobc for use by other modules or functions.
Reviewed By: kib
Obtained from: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D47539
Unusually, the FUSE_NOTIFY_INVAL_INODE and FUSE_NOTIFY_INVAL_ENTRY
messages are fully asynchronous. The server sends them to the kernel
unsolicited. That means that unlike every other fuse message coming
from the server, these two arrive to a potentially unbusied mountpoint.
So they must explicitly busy it. Otherwise a page fault could result if
the mountpoint were being unmounted.
Reported by: JSML4ThWwBID69YC@protonmail.com
MFC after: 2 weeks
Re-ordering the fields suppresses the trailing padding which was causing
the structure to overflow 'struct fid'.
While here, re-indent in a more visually pleasing way.
Reviewed by: rmacklem, emaste, markj
Approved by: markj (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D47955
As the 'gen' field in 'struct tarfs_node' (and then 'struct tarfs_fid')
is filled with arc4random() which returns an unsigned int, change its
type in both structures. This allows reordering fields in 'struct
tarfs_fid' to reduce its size, finally avoiding the use of '__packed' to
ensure it fits into 'struct fid'.
While here, remove the 'data0' field which wasn't necessary from the
start.
Reviewed by: markj, rmacklem, des
Approved by: markj (mentor)
MFC after: 5 days
Differential Revision: https://reviews.freebsd.org/D47954
The --short flag is configurable. Setting an explicit length supports
reproducible builds.
Signed-off-by: Pat Maddox <pat@patmaddox.com>
Reviewed by: emaste, imp
Differential revision: https://github.com/freebsd/freebsd-src/pull/1547
In the ACPI attachment add support for the pcib_request_feature method.
This uses the common _OSC handling.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48048
In the ACPI attachment support the ACPI_IVAR_HANDLE ivar. While here
use the common ivar function to support the common ivars.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48047
Allow this to be called from attachments to allow more ivars to be
implemented.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48046
In pci_host_generic.c use a switch statement rather than a series
of if statements.
Reviewed by: imp
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48045
This will be used by pci_host_generic_acpi.c so needs to be in a
common location.
Reviewed by: imp, jhb
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48044
Switch from creating the msr instructions to manage PAN to use the
"msr pan, #1" instruction directly. When this was added clang didn't
have support to assemble the instructions. This appears to have been
added to clang 13 which is sufficiently old enough.
Binutils releases from around the same time appear to have added this
instruction so any modern gcc should also support this instruction.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47817
When comparing two ID registers to create a common userspace view we
have an option where we set an exact value only if the two are
different. This is only used in one field in the cache type register
that is accessible by userspace without being trapped by the kernel.
In preparation for trapping access to this register to handle it in
the kernel in some situations fix the 'if different' check.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47811
Actually check the conditions that are enforced by the error checking
code instead of a condition which is
* checking a number to be non-negative instead of positive
* depending on a random number
Perform the checks consistently for ICMPv4 and ICMPv6.
Reviewed by: glebius, rrs, cc
MFC after: 1 week
Sponsored by: Netflix, Inc.
Differential Revision: https://reviews.freebsd.org/D48001
This check for SO_REUSEPORT was added way back in commit 52b65dbe85.
Per the commit log, this commit restricted this port-stealing check to
unicast addresses, and then only if the existing socket does not have
SO_REUSEPORT set. In other words, if there exists a socket bound to
INADDR_ANY, and we bind a socket to INADDR_ANY with the same port, then
the two sockets need not be owned by the same user if the existing
socket has SO_REUSEPORT set.
This is a surprising semantic; bugzilla PR 7713 gives some additional
context. That PR makes a case for the behaviour described above when
binding to a multicast address. But, the SO_REUSEPORT check is only
applied when binding to a non-multicast address, so it doesn't really
make sense. In the PR the committer notes that "unicast applications
don't set SO_REUSEPORT", which makes some sense, but also refers to
"multicast applications that bind to INADDR_ANY", which sounds a bit
suspicious.
OpenBSD performs the multicast check, but not the SO_REUSEPORT check.
DragonflyBSD removed the SO_REUSEPORT (and INADDR_ANY) checks back in
2014 (commit 0323d5fde12a4). NetBSD explicitly copied our logic and
still has it.
The plot thickens: 20 years later, SO_REUSEPORT_LB was ported from
DragonflyBSD: this option provides similar semantics to SO_REUSEPORT,
but for unicast addresses it causes incoming connections/datagrams to be
distributed among all sockets in the group. This commit (1a43cff92a)
inverted the check for SO_REUSEPORT while adding one for
SO_REUSEPORT_LB; this appears to have been inadvertent. However:
- apparently no one has noticed that the semantics were changed;
- sockets belonging to different users can now be bound to the same port
so long as they belong to a single lbgroup bound to INADDR_ANY, which
is not correct.
Simply remove the SO_REUSEPORT(_LB) checks, as their original
justification was dubious and their current implementation is wrong; add
some tests.
Reviewed by: glebius
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D47832
For a long time, the inpcb lookup path has been lockless in the common
case: we use net_epoch to synchronize lookups. However, the routines
which update lbgroups were not careful to synchronize with unlocked
lookups. I believe that in the worst case this can result in spurious
connection aborts (I have a regression test case to exercise this), but
it's hard to be certain.
Modify in_pcblbgroup* routines to synchronize with unlocked lookup:
- When removing inpcbs from an lbgroup, do not shrink the array.
The maximum number of lbgroup entries is INPCBLBGROUP_SIZMAX (256),
and it doesn't seem worth the complexity to shrink the array when a
socket is removed.
- When resizing an lbgroup, do not insert it into the hash table until
it is fully initialized; otherwise lookups may observe a partially
constructed lbgroup.
- When adding an inpcb to the group, increment the counter after adding
the array entry, using a release store. Otherwise it's possible for
lookups to observe a null array slot.
- When looking up an entry, use a corresponding acquire load.
Reviewed by: ae, glebius
MFC after: 1 month
Sponsored by: Klara, Inc.
Sponsored by: Stormshield
Differential Revision: https://reviews.freebsd.org/D48020
This commit upgrades the FUSE API to protocol 7.32.
It doesn't implement any of protocol 7.32's new features.
Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D48040
void * is handy when you truly do not care about the type. Yet there is
so much casting back and forth in the IO-APIC code as to be hazardous.
Achieve better static checking by the compiler using a typedef.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1457
Add a workaround for Cortex-A55 erratum 1024718 and Cortex-A510 erratum
2051678. Both errata are related to the hardware handling of the dirty
field in page tables and can be worked around by disabling this feature.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47809
To allow for it to be more selective when we enable it, e.g. if the
CPU has an erratum that prevents us from doing so, move the check for
setting TCR_HD to C.
Reviewed by: alc
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D47808
This was left over from before using atomic(9) consistently. It is
unneeded as these loads are already ordered correctly.
Reviewed by: alc, kib
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D48002
The commit to introduce TCP_USE_DDP support had a couple of bugs that
broke support for zerocopy receive via aio_read(). First, the length
and offset arguments to mk_update_tcb_for_ddp() were reversed which
prevented DDP from working. Second, the AIO state in the toep was
initialized too late when the first aio_read() request was queued.
Reported by: Harshavardhan Tanneru @ Chelsio
Fixes: eba13bbc37 cxgbe: Support TCP_USE_DDP on offloaded TOE connections
MFC after: 1 week
Sponsored by: Chelsio Communications
The termios layer wants some level of guarantee that we've actually
submitted param changes to the hardware when our functions return, so we
need to do a little more waiting to avoid violating those guarantees.
This is especially important as some hardware has some minimum timing
specifications around this stuff, and without being less asynchronous
the software dealing with these devices can't reasonably operate the
hardware without more excessive delays than they should need.
More specifically, we make sure that:
- The command to start transfers is finished before we toggle DTR/RTS
- The status_change command finishes before we return, which may change
some fields in the softc that we need for a subsequent call into
usb_serial
- cfg_param finishes before we re-enable transfers, and we ensure that
RTS is appropriately toggled before we return to userland
This has been observed to fix some flakiness in connecting to some
ESP32 devices.
Tested by: kenrap from Libera
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D47952
ucom_queue_command will issue commands for open/close, then wait on them
to be finished. In the spirit of playing it safe, allow
ucom_queue_command's wait to be interrupted in case the usb process gets
jammed up waiting on the hardware -- we can at least recover the user
thread that initiated it, even if we can't recover the usb process.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D47951
There's only one error that we can get back right now, but future
changes will add some more cases that we need to watch out for. Start
by returning errors and propagating them back.
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D47950
These were typo'd at creation, and they should've used the common
TDA_ prefix. Switch them now. No compat shims because these are niche
enough that it seems unlikely that they've seen large adoption under the
wrong name.
OK'd by: kib
Fixes: c6d31b83 ("AST: rework")
The GPIO controls the multiplexing of the D1 pins to its peripherals,
so this adds the definitions needed by the aw_gpio driver to support
the D1.
Also, this modifies the aw_gpio driver to support the differences of
the D1 controller:
- pins can have up to 15 functions
- each port is mapped with an alignment of 0x30
- CFG registers have 4 bits per pin
- DRV registers have 4 bits per pin
- the offset of PULL registers is 0x24
Signed-off-by: Julien Cassette <julien.cassette@gmail.com>
Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D35593
