Netgraph has two main types of message items:
- NGQF_DATA items are used for data processing. This is a hot path that
should be called from a NET_EPOCH context.
- NGQF_MESG items are used for node configuration. There are many places
in netgraph(4) where processing the NGQF_MESG item can call sections of code
that are forbidden in the NET_EPOCH context.
All item types can be queued and then processed using ngthread().
But ngthread() is unconditionally enter in the NET_EPOCH section for all types.
This causes panic/deadlocks when processing NGQF_MESG elements.
Reported by: mjg
Reviewed by: glebius, vmaffione (mentor)
Tested by: mjg, afedorov
Approved by: glebius, vmaffione (mentor)
Sponsored by: vstack.com
Differential Revision: https://reviews.freebsd.org/D36496
This changes the default TCP Congestion Control (CC) to CUBIC.
For small, transactional exchanges (e.g. web objects <15kB), this
will not have a material effect. However, for long duration data
transfers, CUBIC allocates a slightly higher fraction of the
available bandwidth, when competing against NewReno CC.
Reviewed By: tuexen, mav, #transport, guest-ccui, emaste
Relnotes: Yes
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D36537
Consistently refer to the CUBIC congestion control
mechanism in uppercase throughout all comments.
No functional change.
Reviewed By: #transport, tuexen, mav, guest-ccui, emaste
Sponsored by: NetApp, Inc.
Differential Revision: https://reviews.freebsd.org/D36547
Be more precise in the definition of policy directions
and policy levels.
PR: 250177
Reported by: Bram Ton <bram at cbbg dot nl>
Reviewed by: gbe, ae
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D26719
Change RB_COLOR_INSERT to take a parent parameter, to avoid looking up
a value already available. Make adjustments to a linux rbtree header,
which invokes it.
Reviewed by: alc, hselasky
Differential Revision: https://reviews.freebsd.org/D36114
Fix compilation warning/errors - in this instance we do need the register
IO.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36535
* remove dead code
* mark enabled as unused, happens if debugging isn't enabled
* log the enabled state if debugging is enabled
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36533
Changes in compilers / warnings/errors caused this to stop compiling.
Delete the write-only code.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36532
hw.cxgbe.cong_drop=2 will generate backpressure *and* drop frames for
queues that are congested.
MFC after: 2 weeks
Sponsored by: Chelsio Communications
Test that we can successfuly set syncookie high/low watermarks for very
low or very high state limits.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36498
Ensure that we always pass sane limits for the high and low watermark
values.
This is especially important if users do something silly, like set the
state limit to 1. In that case we wound up calculating 0/0 as a limit,
which gets rejected by the kernel.
While here also shift the calculation to use uint64_t, so we don't end
up with overflows (and subsequently higher low than high values) with
very large state limits.
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D36497
Summary:
This mirrors the recentish changes to armv8; the ipq4018 port uses
dwc3 + xhci and thus needs this.
Subscribers: imp, andrew
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36530
usbhid(4) vs other USB HID drivers precedence is determined by
hw.usb.usbhid.enable loader tunable and HID quirk subsystem rather
than by device_probe() return value. Raise priority high enough to
always give usbhid(4) a possible chance to attach.
Fixes usbhid(4) attachment on USB device hotplug.
Reported by: Ivan Quitschal <tezeka_AT_hotmail_DOT_com>
MFC after: 1 week
When attempting to promote 4KB user-space mappings to a 2MB user-space
mapping, the address of the struct vm_page representing the page table
page that contains the 4KB mappings is already known to the caller.
Pass that address to the promotion function rather than making the
promotion function recompute it, which on arm64 entails iteration over
the vm_phys_segs array by PHYS_TO_VM_PAGE(). And, while I'm here,
eliminate unnecessary arithmetic from the calculation of the first PTE's
address on arm64.
MFC after: 1 week
kern.cam.da.default_softtimeout currently does nothing. It sets a value
in the CCB that SIMs could look at, only none do. Leave it undocumented
until it actually does something. It was introduced to allow a 'soft
recovery' to be started when things were taking too long in the SIM by
not scheduling new I/O, or other measures the SIM knew would help when
it seemed like things were getting 'backed up'. No SIM in the FreeBSD
tree implements this and scsi_da doesn't use it other than to pass it
down, so best remove it from the documentation until it does something.
Sponsored by: Netflix
Fixes: 53af9c235f
Reviewed by: gbe
Differential Review: https://reviews.freebsd.org/D36518
The ls(1) (with -l option) and find(1) (with -ls option) utilties
segment fault when operating on files with very large modification
times. A recent disk corruption set a spurious bit in the mtime
field of one of my files to 0x8000000630b0167 (576460753965089127)
which is in year 18,266,940,962. I discovered the problem when
running fsck_ffs(8) which uses ctime(3) to convert it to a readable
format. Ctime cannot fit the year into its four character field, so
returns ??? ??? ?? ??:??:?? ???? (typically Thu Nov 24 18:22:48 2021).
With the filesystem mounted, I used `ls -l' to see how it would
report the modification time and it segment faulted. The find(1)
program also segment faulted (see script below). Both these utilities
call the localtime(3) function to decode the modification time.
Localtime(3) returns a pointer to a struct tm (which breaks things
out into its component pieces: year, month, day, hour, minute,
second). The ls(1) and find(1) utilities then print out the date
based on the appropriate fields in the returned tm structure.
Although not documented in the localtime(3) manual page, localtime(3)
returns a NULL pointer if the passed in time translates to a year
that will not fit in an "int" (which if "int" is 32-bits cannot
hold the year 18,266,940,962). Since ls(1) and find(1) do not check
for a NULL struct tm * return from localtime(3), they segment fault
when they try to dereference it.
When localtime(3) returns NULL, the attached patches produce a date
string of "bad date val". This string is chosen because it has the
same number of characters (12) and white spaces (2) as the usual
date string, for example "Sep 3 22:06" or "May 15 2017".
The most recent ANSI standard for localtime(3) does say that localtime(3)
can return NULL (see https://pubs.opengroup.org/onlinepubs/9699919799/
and enter localtime in the search box). Our localtime(3) man page should
be updated to indicate that NULL is a possible return. More importantly,
there are over 100 uses of localtime(3) in the FreeBSD source tree (see
Differential Revision D36474 for the list). Most do not check for a NULL
return from localtime(3).
Reported by: Peter Holm
Reviewed by: kib, Chuck Silvers, Warner Losh
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36474
Fix types for various struct fields (initially added as int).
Move structs and inline functions logically together, e.g., for wowlan.
Add more skeleton functions and #defines needed for iwlwifi d3.c
in the future.
Add struct ieee80211_vht_cap (without "_ie") to net80211 and remove
duplicate definitions in LinuxKPI headers now using net80211 structs.
For now leave ieee80211_ie_vhtcap in net80211. I am not sure yet if we
actually need it as such. That'll be cleaned up with more VHT updates
in net80211 in the future.
No functional changes in currently compiled code intended.
Try to implement ieee80211_action_contains_tpc() as I ran into it with
an older iwlwifi chipset. This depends on c994352a88.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Import the most recent versions of the firmware images for the
rtw89 driver.
This is based on linux-firmware at 2f2f0181581d3e35bfdb9fc65f609ee9d3fbaeb7.
The license of the firmware matches the previously added rtw88(4) firmware
and you can find a copy in sys/contrib/dev/rtw89fw/LICENCE.rtlwifi_firmware.txt.
Add build infrastructure to create the .ko files but do not yet hook
it up to the build until all parts are in the tree.
Approved by: core.11 (imp) [2022-03-27]
MFC after: 6 weeks
