The TLS receive tags are allocated directly from the receiving interface,
because mbufs are flowing in the opposite direction and then route change
checks are not useful, because they only work for outgoing traffic.
Differential revision: https://reviews.freebsd.org/D32356
Sponsored by: NVIDIA Networking
Remove bounce buffering code for blkback and only attach if Xen
creates IOMMU entries for grant mapped pages.
Such bounce buffering consumed a non trivial amount of memory and CPU
resources to do the memory copy, when it's been a long time since Xen
has been creating IOMMU entries for grant maps.
Refuse to attach blkback if Xen doesn't advertise that IOMMU entries
are created for grant maps.
Sponsored by: Citrix Systems R&D
Handle tearing down a blkback that hasn't been fully initialized. This
requires carefully checking that fields are allocated before trying to
access them. Also communication memory is allocated before setting
XBBF_RING_CONNECTED, so gating it's freeing on XBBF_RING_CONNECTED
being set is wrong and will lead to memory leaks.
Also stop using xbb_disconnect() in error paths. Use xenbus_dev_fatal
and let the normal disconnection procedure take care of the cleanup.
Reported by: Ze Dupsys <zedupsys@gmail.com>
Sponsored by: Citrix Systems R&D
xenbus needs to keep track of the devices exposed on xenstore, so that
it can trigger frontend and backend device creation.
Removal of backend devices is currently detected by checking the
existence of the device (backend) xenstore directory, but that's prone
to races as the device driver would usually add entries to such
directory itself, so under certain circumstances it's possible for a
driver to add node to the directory after the toolstack has removed
it. This leads to devices not removed, which can eventually exhaust
the memory of FreeBSD.
Fix this by checking for the existence of the 'state' node instead of
the directory, as such node will always be present when a device is
active, and will be removed by the toolstack when the device is shut
down. In order to avoid any races with the updating of the 'state'
node by FreeBSD and the toolstack removing it use a transaction in
xenbusb_write_ivar() for that purpose.
Reported by: Ze Dupsys <zedupsys@gmail.com>
Sponsored by: Citrix Systems R&D
Adding a few KASSERT() to validate sanity of sack holes, and
bail out if sack hole is inconsistent to avoid panicing non-invariant builds.
Reviewed By: hselasky, glebius
PR: 263445
MFC after: 1 week
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D35387
This allows to profile already running high-priority threads, that
otherwise by blocking thread migration to respective CPUs blocked PMC
management, i.e. profiling could start only when workload completed.
While there, return the thread to its original CPU after iterating
the list. Otherwise all threads using PMC end up on the last CPU.
MFC after: 1 month
This ensures read-only PT_LOAD segments are not marked as writable in
the phdr flags.
Reviewed by: markj
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D35398
In iommu_gas_lowermatch and iommu_gas_uppermatch, a subtree search is
quickly terminated if the largest available free space in the subtree
is below a limit, where that limit is related to the size of the
allocation request. However, that limit is too small; it does not
account for both of the guard pages that will surround the allocated
space, but only for one of them. Consequently, it permits the search
to proceed through nodes that cannot produce a successful allocation
for all the requested space. Fix that limit to improve search
performance.
Reviewed by: alc, kib
Submitted by: Weixi Zhu (wxzhu@rice.edu)
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D35414
Make it a complex, but a single for(;;) statement. The previous cycle
with some loop logic in the beginning and some loop logic at the end
was confusing. Both me and markj@ were misleaded to a conclusion that
some checks are unnecessary, while they actually were necessary.
While here, handle an edge case found by Mark, when on 64-bit platform
an incorrect message from userland would underflow length counter, but
return without any error. Provide a test case for such message.
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D35375
Summary:
It can be useful to see a summary of CPU caches on bootup. This is done
for most platforms already, so add this to arm64, in the form of (taken
from Apple M1 pro test):
L1 cache: 192KB (instruction), 128KB (data)
L2 cache: 12288KB (unified)
This is printed out per-CPU, only under bootverbose.
Future refinements could instead determine if a cache level is shared
with other cores (L2 is shared among cores on some SoCs, for instance),
and perform a better calculation to the full true cache sizes. For
instance, it's known that the M1 pro, on which this test was done, has 2
12MB L2 clusters, for a total of 24MB. Seeing each CPU with 12288KB L2
would make one think that there's 12MB * NCPUs, for possibly 120MB
cache, which is incorrect.
Sponsored by: Juniper Networks, Inc.
Reviewed by: #arm64, andrew
Differential Revision: https://reviews.freebsd.org/D35366
Make sure to check for NULL pointers and also check all search criterias,
not only the first one!
Bump the FreeBSD version.
Reviewed by: manu@
Differential Revision: https://reviews.freebsd.org/D35403
MFC after: 1 week
Sponsored by: NVIDIA Networking
In lkpi_sta_assoc_to_run() we are going through some code segments
twice (auth->assoc, assoc->authorized). The 2nd time we shall not
re-gain a reference on the net80211 node as otherwise it'll leak.
Likewise we do not have to re-set lsta and sta.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Based on manual inspection the skbs are not freed in those unlikely
cases, though all would give an error message so would have gone noticed
if happened.
While here fix a typo in one of these error messages.
MFC after: 3 days
Manually free the mbuf in certain error cases from net80211 to not
leak it.
Note that the differences between ieee80211_input_mimo() and
ieee80211_input_mimo_all(), the former not consuming the mbuf while
the later does, is confusing.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
I completely forgot about updating the generated llvm-project config
files, which also contain version numbers, etc. Sorry for the churn.
PR: 261742
Fixes: ab9d54731f
MFC after: 3 days
It is unclear why this hasn't bothered anyone in months; I can only assume
optimization levels but it seems there were unresolved symbols in
iwlwifi after d9836fb4b9:
link_elf_obj: symbol iwl_mvm_send_roaming_forbidden_event undefined
Hide more of the currently unsupported (GPL-only) MEI (Management Engine)
code behind #ifdef to avoid this.
Reported by: dchagin
Tested by: dchagin
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
By analogy with IP address matching, add a way to use ipfw radix
tables for MAC matching. This is implemented using new ipfw table
with mac:radix type. Also there are src-mac and dst-mac lookup
commands added.
Usage example:
ipfw table 1 create type mac
ipfw table 1 add 11:22:33:44:55:66/48
ipfw add skipto tablearg src-mac 'table(1)'
ipfw add deny src-mac 'table(1, 100)'
ipfw add deny lookup dst-mac 1
Note: sysctl net.link.ether.ipfw=1 should be set to enable ipfw
filtering on L2.
Reviewed by: melifaro
Obtained from: Yandex LLC
MFC after: 1 month
Relnotes: yes
Sponsored by: Yandex LLC
Differential Revision: https://reviews.freebsd.org/D35103