A test helper program pcap-test allows to capture, inject and compare.
Build a simple test case on top of it. More test cases can be easily
constructed.
Do not create mutexes with snd_mtxcreate(). It doesn't provide any
value, plus it first allocates the mutex with malloc(9). Allocate
mutexes in the stack and use mtx_* functions directly instead of the
snd_mtx* wrappers.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D53855
There is no scenario where chn_intr() is called with the channel lock
already held.
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D53854
PCM_ALIVE() is used only in pcm_unregister(), but it does not hurt to
use PCM_REGISTERED(), which uses PCM_ALIVE() internally. In fact, it's
more robust this way.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Use CHN_LOCK()/CHN_UNLOCK() directly, instead of
dsp_lock_chans()/dsp_unlock_chans(). These functions are useful when we
want to potentially lock both channels. Here we know which channel we
are locking, so we can just lock it directly. This way we get rid of the
prio variable as well.
Related to runpid again, there is no reason to assign it when
CHN_F_RUNNING is not set. channel->pid (as well as channel->comm) is
always assigned in dsp_chn_alloc().
Get rid of runpid. I do not see how we can end up with channel->pid
(td->td_proc->p_pid) not matching buf->uio_td->td_proc->p_pid.
Also improve errno values.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D53736
This is the only place this important debugging tunable is documented.
Mark it up with the Va macro according to style.mdoc(5) so that people
can find it via `apropos Va=kern.msg`, the standard syntax to search
the FreeBSD manual for sysctls and tunables.
Fixes: 6910fee62e (dmesg: Document kern.msgbuf_show_timestamp)
In c12013f5bb we fixed udp_mapping cleanup issues in pf_get_sport(), but
missed the static-port case (i.e. low == 0 && high == 0). We could still exit
pf_get_sport() without either inserting the udp_mapping or freeing it.
Address this and add a test case to provoke the problem.
Reviewed by: thj
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D53856
Compiled under INVARIANTS, activated by the same sysctl
debug.vm_check_pg_zero.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D53850
Make the check MI by allocating sf_buf in non-blockable manner. For
DMAP arches, this should be nop since sf_buf allocation cannot fail
trivially. For non-DMAP arches, we get the checks activated unless there
is serious sf_buf pressure, which typically should be not.
The context for vm_page_free_prep() should be ready to block on some VM
mutexes, which should make it reasonable to block on sf_buf list lock.
Move the code to INVARIANTS build from DIAGNOSTIC, and control its activation
with the sysctl debug.vm_check_pg_zero.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D53850
* tag packets for 11n/11ac associated nodes with A_MPDU so they
get passed into the reordering logic
* tag A-MSDU frames with AMSDU and AMSDU_MORE so they don't get
dropped due to duplicate sequence numbers.
Note: I haven't yet elicited A-MSDU in A-MPDU to fully test this,
but I do see the net80211 reordering logic kick in (which you can
see via wlanstats -i wlan0 -o ampdu 1).
I've checked with Johannes Berg at Intel (who maintains the linux
iwlwifi stuff); he replied saying none of the firmware versions are
doing AMPDU reorder offloading.
Differential Revision: https://reviews.freebsd.org/D53781
Locally tested:
* AX210, STA mode, > 200mbit bidirectional traffic testing on
5GHz VHT/40.
Reporter noted packet loss with 82583. NVM is down level. The
errata docs mention disabling this, which should be the firmware
default, so I am not sure why we were enabling this bit. Linux and
OpenBSD have the same issue, while NetBSD got it right.
Reported by: Codin <codin@nagi.ftp.sh>
Tested by: Codin <codin@nagi.ftp.sh>
MFC after: 2 weeks
The reporter contacted me with packet loss and throughput fluctuations
on a low power machine (Intel J1900) that got worse with the recent AIM
algorithm in FreeBSD 14.2+.
32K RX PBA matches Linux default. Add a conditional path since we don't
otherwise do a fixup for jumbo frames to retain space for two frames in
Tx.
With this change and an additional errata change, the throughput meets
line rate for the reporter.
Reported by: Codin <codin@nagi.ftp.sh>
Tested by: Codin <codin@nagi.ftp.sh>
MFC after: 2 weeks
When iterating over known addresses for the requested target host name,
skip those that are not supported by the running kernel.
MFC after: 1 week
PR: 195231
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D53588
Use the protype socket to obtain the IP address for an error message.
Using the resultant socket address, a NULL because create_interface()
had failed, results in SIGSEGV.
To reproduce this bug,
ifconfig bridge100 create
ifconfig bridge100 10.10.10.10/24
ifconfig bridge101 create
ifconfig bridge101 10.10.10.10/24
ntpd -n
PR: 291119
MFC after: 3 days
Release notes are generated using this text.
I used "interfaces" not "adapters" in these pages as the listed devices
are the controller ICs, not end-user projects.
Reviewed by: ziaee
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53846
INVARIANTS kernels may trigger a KASSERT panic from sndbuf_acquire(),
when fuzzing write(2) using stress2, because of a race in chn_write().
In the case of chn_write(), what sndbuf_acquire() does is extend the
ready-to-read area of the buffer by a specified amount of bytes. The
KASSERT in question makes sure the number of bytes we want to extend the
ready area by, is less than or equal to the number of free bytes in the
buffer. This makes sense, because we cannot extend the ready area to
something larger than what is available (i.e., free) in the first place.
What chn_write() currently does for every write is; calculate the
appropriate write size, let's say X, unlock the channel, uiomove() X
bytes to the channel's buffer, lock the channel, and call
sndbuf_acquire() to extend the ready area by X bytes. The problem with
this approach, however, is the following.
Suppose an empty channel buffer with a length of 1024 bytes, and 2
threads, (A) and (B), where (B) is a higher-priority one. Suppose thread
(A) wants to write 1024 bytes. It unlocks the channel and uiomove()s
1024 bytes to the channel buffer. At the same time, thread (B) picks up
the lock, and because it is higher priority, it keeps dominating the
lock for a few iterations. By the time thread (A) picks up the lock
again, it tries to call sndbuf_acquire() with a size of 1024 bytes,
which was calculated before it performed the uiomove(). In this case,
there is a very high chance that the buffer will not be empty, that is,
have a free area of 1024 bytes, as was the case when thread (A) started
executing, and so the KASSERT will trigger a panic because the condition
(bytes <= free) is not met.
Another scenario that can trigger a panic is the following: suppose a
buffer with a size of 4 bytes, and two threads: (A) and (B). In the
first iteration, thread (A) wants to write 2 bytes, while the buffer is
empty, BUT the pointer (sndbuf_getfreeptr()) is at the end (i.e.,
buf[3]). In the first iteration of the loop, because of the way we
calculate t, we'll end up writing only 1 byte, so after sz -= t, sz will
be 1, and so we'll need one more iteration in the inner loop, to write
the remaining 1 byte. Now we're at the end of the first loop, thread (A)
unlocks the channel, it has written 1 byte, it needs to write 1 more,
and the buffer is left with 3 empty slots. Now thread (B) picks up the
lock, and it wants to write 3 (or more) bytes. Eventually it writes the
3 bytes, and it leaves the buffer with 0 free slots. By the time thread
(A) picks up the lock again, and continues with the second iteration of
the inner loop, it will try to write the last byte, but sndbuf_acquire()
will panic because there is no free space anymore.
To fix this, get rid of the inner loop and calculate the write size on
each iteration. Also, call sndbuf_acquire() before unlocking the
channel. In the scenarios explained above, we'll end up entering the
chn_sleep() case. Modify it as well, so that we do not kill the channel
if we need to sleep more.
Do the same for chn_read() to avoid possible similar panics from
sndbuf_dispose().
Reported by: pho
Tested by: christos, pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: pho, kib
Differential Revision: https://reviews.freebsd.org/D53666
Reported by: andrew, rpokala
Fixes: 8d2a50bb38 ("nvme: Abstract out function to obtain a disk ident string from cdata")
Sponsored by: Chelsio Communications
Use the same check as iflib_if_transmit() to detect when the
interface is down and return the proper error code, and also
free the mbuf.
This fixes an mbuf leak when a member of a lagg is brought
down (and probably many other scenarios).
Sponsored by: Netflix
39d4094173 ("epair: add support for checksum offloading") revealed
that HW checksum offloading is not enabled when the dpaa2_ni driver
is attached despite being declared and enabled on the dpni interface.
I modified dpaa2_ni_setup_if_caps to take into account both IPv4 and
IPv6 checksum offloading capabilities and added a call to re-configure
interface capabilities on attach to fix it.
Reviewed by: bz
Fixes: 39d4094173 ("epair: add support for checksum offloading")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53436
Calling dotrap() can do almost anything, including reallocating the
jobtab array. Convert the job pointer to an index before calling
dotrap() and then restore a proper job pointer afterwards.
PR: 290330
Reported by: bdrewery
Reviewed by: bdrewery
Differential Revision: https://reviews.freebsd.org/D53793
Prior to this commit, we were shipping 2155 MB of packages (from the
ports tree, not counting pkgbase) on dvd1.iso. Due to the amount of
space required by shipping pkgbase packages *and* distribution sets
on the DVD images, we only have 1696 MB available if we want to fit
into the 4.7 GB limit for DVDs. Many users have indicated that this
is indeed important.
It is practically impossible to hit this target without removing KDE;
while KDE and its dependencies narrowly fit (1550 MB), we exceed the
limit as soon as we include either of freebsd-doc-all or gnome. While
we would pick KDE over GNOME (surveys regularly indicate that KDE is
the more widely used of the two), we believe that documentation is the
most important thing to include.
Since removing KDE leaves a bit of extra space, add editors/emacs and
editors/vim. This takes the 15.0 amd64 dvd1.iso up to 4.689 GB. [1]
Requested by: adamw [1]
MFC after: immediately (for 15.0-RC3)
Differential Revision: https://reviews.freebsd.org/D53800
The previous implementation implemented hostfwd rules which would allow
the host to connect to the guest via a NATed TCP connection. libslirp
also permits NAT in the other direction, but this was prevented by
bhyve's capsicum sandbox.
To make the slirp backend more useful, split the backend out into a
separate process which does not enter capability mode if outbound
connections are permitted (enabled by setting the new "open" keyword).
The process communicates with the bhyve network frontend (typically a
virtio network interface) using a unix SOCK_SEQPACKET socket pair. If
the bhyve process exits, the helper will automatically exit.
Aside from this restructuring, there is not much actual change. Many
slirp parameters are still hard-coded for now, though this may change.
The "restricted" feature is toggled by the new "open" keyword; in
particular, the backend is restricted by default for compatibility with
15.0 and 14.3.
Each packet now has to traverse an extra socket, but this overhead
should be acceptable given that the slirp backend cannot be said to
provide high-performance networking. With iperf3 I can get 4Gbps from
the guest to the host on a Zen 4 system.
MFC after: 1 month
Sponsored by: CHERI Research Centre (EPSRC grant UKRI3001)
Differential Revision: https://reviews.freebsd.org/D53454
Peter Holm