mgb.4, muge.4: Use standard HARDWARE introduction
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
max_align_t: apply alignof to 'long double' for long double alignment
Reviewed by; markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D53826
ipfw: Retire obsolete compat code
The current IPFW version 3 dates to 2010 (commit cc4d3c30ea28, "Bring in
the most recent version of ipfw and dummynet, developed").
The compat code for FreeBSD 8 and earlier has a number of issues and is
no longer needed, so remove it.
Reported by: Ilja Van Sprundel <ivansprundel at ioactive.com>
Reviewed by: ae, glebius
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D53343
(cherry picked from commit c59aab9a5b3970b3ccec744f759e6cb87e938dbe)
(cherry picked from commit 9657c50cdd7741404d99881fdd9243175086ede1)
sound: Fix KASSERT panics in chn_read() and chn_write()
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
[43 lines not shown]
nvme: Include <sys/systm.h> explicitly for memmove
Reported by: andrew, rpokala
Fixes: 8d2a50bb3805 ("nvme: Abstract out function to obtain a disk ident string from cdata")
Sponsored by: Chelsio Communications
ObsoleteFiles.inc: Fix up incorrect merge
This is a direct commit to stable/15.
Reported by: des
Fixes: 838c8027f9d8 ("libexec/kgdb: Add new modules and install them together with debug info")
sound: Retire SND_DIAGNOSTIC PCM locking macros
Disabled by default, but also redundant, since most of the errors they
catch will be caught anyway by WITNESS and the locking subsystem.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D53735
(cherry picked from commit b19e61f223a1982cce103b9716568391a071892a)
sound: Move mixer->modify_counter to more appropriate place
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
(cherry picked from commit 15d77c1fdcb1c7f022a21892dcb78990986f1a3c)
cuse: Fix cdevpriv bugs in cuse_client_open()
If devfs_set_cdevpriv() fails, we will panic when we enter the
cuse_client_free() callback, for a number of reasons:
- pcc->server is not yet assigned, so we'll use a NULL pointer.
- pcc has not yet been added to the pcs->hcli TAILQ, but we'll try to
remove it.
- pccmd->sx and pccmd->cv are not yet initializated, but we'll try to
destroy them.
Even if we'd get past all these somehow, we'd still get two errors in
the devfs_set_cdevpriv() failure block:
- We'll unref the server twice, once in cuse_client_free(), and again in
cuse_client_open().
- A double-free panic, since we'd be trying to free(pcc), which has
already been freed in cuse_client_free().
[9 lines not shown]
sound: Remove unnecessary uio checks in dsp_io_ops()
uiomove_faultflag() takes care of that already.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D53733
(cherry picked from commit 6b5431941c10b6fdf164ad9d3dfa4b4f1b2edc22)
sound: Retire OLDPCM_IOCTL
It is defined by default, and there is no reason to have a switch for
it. While here, also get rid of some unnecessary comments and ioctl
definitions.
No functional change intended.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
(cherry picked from commit 1fe7bfd6c70160c064237eac104e7d9c71390c4f)
Use install instead of cp to copy bootstrap tools
We need to preserve modification times on bootstrap tools, but `cp -p`
also tries to preserve flags, which fails if OBJROOT is on NFS. A -N
option was added to cp for this purpose, but trying to use that would
break cross-building on hosts that don't have that option. The best
remaining option is `install -p`, which we already assume is present.
PR: 275030
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D53751
(cherry picked from commit f3cf4c0af5af6ce95065a615f998117ec1cd63aa)
Use install instead of cp to copy bootstrap tools
We need to preserve modification times on bootstrap tools, but `cp -p`
also tries to preserve flags, which fails if OBJROOT is on NFS. A -N
option was added to cp for this purpose, but trying to use that would
break cross-building on hosts that don't have that option. The best
remaining option is `install -p`, which we already assume is present.
PR: 275030
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D53751
(cherry picked from commit f3cf4c0af5af6ce95065a615f998117ec1cd63aa)
