ttymsg: Overhaul
* Instead of an error string, return the usual 0 or -1 and let the caller
figure out what, if anything, to tell the user.
* Avoid string manipulations by opening /dev first and using openat()
with O_RESOLVE_BENEATH.
* Add a boolean argument which, if false, causes ttymsg() to return
without sending the message if the tty's group-writable bit is not
set. This saves programs that respect this setting (like syslogd(8))
from having to check before calling ttymsg().
* Update all callers.
The observable effect of this change is minimal except for slightly
different error messages when ttymsg() fails. However, syslogd(8) will
no longer print spurious error messages on the console after trying and
failing to write a log message to an X11 session.
[7 lines not shown]
ttymsg: Overhaul
* Instead of an error string, return the usual 0 or -1 and let the caller
figure out what, if anything, to tell the user.
* Avoid string manipulations by opening /dev first and using openat()
with O_RESOLVE_BENEATH.
* Add a boolean argument which, if false, causes ttymsg() to return
without sending the message if the tty's group-writable bit is not
set. This saves programs that respect this setting (like syslogd(8))
from having to check before calling ttymsg().
* Update all callers.
The observable effect of this change is minimal except for slightly
different error messages when ttymsg() fails. However, syslogd(8) will
no longer print spurious error messages on the console after trying and
failing to write a log message to an X11 session.
[7 lines not shown]
inpcb: a pcb may travel only from the wild hash to exact, not vice versa
The only possible way to exercise in_pcbrehash() is to bind(2) and then
connect(2). The second branch was a dead code since fdb987bebddf.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57241
nfsd: Allow vfs.nfsd.srvmaxio to be up to 4Mbytes
Without this patch, the maximum setting for
vfs.nfsd.srvmaxio was 1Mbyte. This patch increases
that to 4Mbytes.
The same as for any setting above 128Kbytes, settings up to
4Mbytes require that kern.ipc.maxsockbuf be increased.
(A message generated after setting vfs.nfsd.srvmaxio via
the /etc/rc.conf variable nfs_server_maxio will indicate
the minimum setting, which will be somewhat greater than
four times the setting of vfs.nfsd.srvmaxio.)
(cherry picked from commit b92b9da3300655c86dcd42ea8a5ba45badd90847)
subr_uio.c: Remove a KASSERT() for large NFS server I/O
When the NFS server is set to allow an I/O size greater
than 1Mbyte (not allowed in FreeBSD's main yet), a
KASSERT() in allocuio() can fail when:
zfs_freebsd_write()->zfs_write()->zfs_uiocopy()
->cloneuio()->allocuio()
is called for a large NFS server write.
Since the userland API callers to allocuio() already
check that the size does not exceed UIO_MAXIOV,
there does not seem to be a need to a KASSERT()
here.
Removing the KASSERT() allows NFS server writes
of greater than 1Mbyte to work, once the NFS code
is patched to allow them.
(cherry picked from commit 13d3bd165e225eec9af91b6e3361c2482931f95b)
install: Bump compare size limit (128MB) to support large binaries
Preserve metadata and prevent redundant disk writes during builds with
the install's -C (compare) flag.
The previous historical comparison limit of 16MB is insufficient for
modern toolchains, frequently choked or bypassed by a large base
components like LLVM/Clang, kernels, Rust apps, and large runtime
libraries.
By leaving matching files alone, install keeps their modification timestamps
intact. make(1) safely ignores those files on subsequent runs.
Base examples: 15.0 amd64 GENERIC kernel - 28MB, clang - 105MB, lldb - 97MB, etc.
Reviewed by: glebius
Approved by: glebius (mentor)
Obtained from: Fudo Security
MFC after: 2 weeks
[2 lines not shown]
syslogd: Fix ereregex property filters and add test
This change fixes Bug 293879, where ereregex filters in syslogd
did not handle alternation correctly.
The issue appears to come from mixing up two different kinds of
flags: syslogd's internal serialized filter flags in
usr.sbin/syslogd/syslogd.h, and the regex compilation flags from
include/regex.h. ereregex was storing REG_EXTENDED in cmp_flags,
even though cmp_flags is meant to carry syslogd's own FILT_FLAG_*
values for configuration serialization and reconstruction.
REG_EXTENDED has the same bit value as FILT_FLAG_EXCLUDE, so the
filter could be reconstructed with the wrong semantics.
The fix stores FILT_FLAG_EXTENDED instead, allowing syslogd to
correctly REG_EXTENDED when compiling the regex.
A test was also added for both ereregex and !ereregex filters.
[8 lines not shown]
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
netmap: silence -Wdefault-const-init-field-unsafe warning
The netmap_ring struct starts with various const members and rencent
clang warns about leaving them uninitialized. Having them const in the
first place is highly suspicious since they are updated with various
macros but using hand-coded __DECONST(). But fixing that is a more
invasive change that I am unable to test.
```
.../freebsd/sys/dev/netmap/netmap_kloop.c:320:21: error: default initialization of an object of type 'struct netmap_ring' with const member leaves the object uninitialized [-Werror,-Wdefault-const-init-field-unsafe]
320 | struct netmap_ring shadow_ring; /* shadow copy of the netmap_ring */
| ^
.../freebsd/sys/net/netmap.h:290:16: note: member 'buf_ofs' declared 'const' here
290 | const int64_t buf_ofs;
| ^
```
Test Plan: Compiles
[5 lines not shown]
if_ovpn.c: fix use of uninitialized variable
In case we use OVPN_CIPHER_ALG_NONE, the memcpy will attempt to copy 0
bytes from an uninitialized pointer. While the memcpy() implementation
will treat this as a no-op and not actually dereferece the undefined
variable it is still undefined behaviour to the compiler and should be
fixed. Found by building with clang HEAD
Reviewed by: kp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D52543
(cherry picked from commit 969be39fb3caf4272f128dbf3267ceba5966a6ce)
ucode: Fix validation on Intel platforms
The check for the extended signature table was backwards, so we always
ignored it.
We should verify that the extended signature table fits within the total
image size.
Reviewed by: jrm, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D57209
ctl: Use CAM_PRIORITY_NORMAL for queued CCBs
Previously this was using CAM_PRIORITY_NONE which tripped over the
assertion added in b4b166b8c46b8.
PR: 293076
Reported by: Ken J. Thomson <thomsonk at yandex.com>
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D56995
ctld: Only check physical port linking in a single configuration context
Commit 969876fcee57 moved struct pport from being per-configuration to
being a "global" object shared across multiple configurations. As a
result, the check for duplicate ports actually spanned across
configurations, such that reloading a configuration would now think
that existing physical ports were already linked.
The linking field in pport added in the C++-ification (commit
6acc7afa34aa) faithfully replicated this bug (albeit simpler as I had
noticed that the TAILQ links weren't used after the earlier commit).
To restore the desired behavior, remove the linking field from struct
pport entirely and use a local unordered_map in conf::add_pports which
tracks if a given pport is claimed by more than one target.
PR: 293076
Reported by: Ken J. Thomson <thomsonk at yandex.com>
Fixes: 969876fcee57 ("ctld: parse config file independently of getting kernel info")
[2 lines not shown]
ctld: Refactor ioctl port handling
- Normalize ioctl port names when the port name is first added to
the configuration. This can catch potential duplicate port names
sooner and helps with other parts of this change.
- When recognizing existing ioctl ports, always expand the name to
include the physical and virtual port numbers. This permits binding
ioctl/0/0 or ioctl/1/0 to a target, for example.
- When adding physical ports to a target, first check for an existing
kernel port to reuse. This handles both ioctl and non-ioctl ports
and removes the need for the conf::add_port method for ioctl ports
to check in kports.
- If an existing kport isn't found when adding physical ports, check
to see if the port name is an ioctl port. If so, call conf::add_port
to add an ioctl port. This add_port method overload is now simpler
as it always creates a new port.
[9 lines not shown]
rk_gpio: implement PIC masking methods and mask unhandled IRQs
The Rockchip GPIO controller implements PIC operations for the INTRNG
framework but is missing four masking methods that INTRNG calls during
the filter/ithread handoff: pic_disable_intr, pic_enable_intr,
pic_pre_ithread, pic_post_ithread.
Without them, level-sensitive interrupt sources connected to a
Rockchip GPIO pin re-fire continuously while their ithread runs. On
a RockPro64 with a FUSB302B Type-C controller (i2c) attached to
gpio1 INT_N, the system enters a ~210 kHz interrupt storm the moment
the fusb302 driver attaches and INT_N goes low.
Two complementary changes:
1. Add the four pic_disable_intr/pic_enable_intr/pic_pre_ithread/
pic_post_ithread method bodies. Each toggles the pin's
RK_GPIO_INTMASK bit so the source is masked during the in-flight
ithread window and unmasked on return, honouring the generic
[17 lines not shown]
bcm2835_sdhci: Clean up DMA resources on attach failure
bcm_sdhci_attach() allocates a DMA channel with bcm_dma_allocate()
before creating the bus_dma tag and map. If a later initialization
step fails, the common error path releases the interrupt and memory
resources, but leaves the DMA channel allocated.
Call bcm_dma_free() for cleanup, as it already performs the required
internal checks and can therefore be invoked directly.
Signed-off-by: Haoxiang Li <lihaoxiang at isrc.iscas.ac.cn>
Reviewed by: mhorne
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2241
cap_mkdb: Fix memory leak
This is not a big deal since it only iterates once before exiting, but
that's no reason to set a bad example.
PR: 195128
MFC after: 1 week
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D57251
limits: Improve consistency
Historical precedent seems pretty consistent: size limits have singular
names, number limits have plural names. RLIMIT_VMM broke this, and I
made matters worse by referring to this limit as “vmms” in limits(1).
Consistently use “vms” everywhere user-visible, while leaving the
question of whether or not to rename RLIMIT_VMM itself for another day.
Fixes: 1092ec8b3375 ("kern: Introduce RLIMIT_VMM")
Fixes: 53af2026f213 ("limits: Unbreak after RLIMIT_VMM addition")
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D57265
sound: Retire snd_mixer->enuminfo
Instead of caching this when mix_setrecdevs() is called (which many
drivers never call), calculate it when we need it. After all, it is
quite rare that this structure is used by applications.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
