arm64 pmap: correct the condition for flushing the icache
Whenever we create a user-space mapping, we always set ATTR_S1_PXN in
the PTE, which blocks execution of user-space code while running in
kernel mode. However, when seeking to determine whether we need to
perform an icache flush before installing the new PTE, we test whether
sometimes the old PTE or other times the new PTE has ATTR_S1_XN set.
The trouble is that ATTR_S1_XN is defined as the bitwise OR of
ATTR_S1_PXN and ATTR_S1_UXN, and so the test for whether ATTR_S1_XN is
set is satisfied if either of its constituent bits is set, i.e., we
write (l3e & ATTR_S1_XN) != 0. Consequently, the test is always true.
In practice, I believe that the ill effects of this bug are limited:
In pmap_enter(), in rare circumstances, e.g., wiring a code page, an
unnecessary icache flush will be performed. In pmap_enter_l2() and
pmap_enter_l3c(), no icache flush will be performed. However,
typically an icache flush would have already been performed on each of
the constituent base pages.
(cherry picked from commit 57407179be431dbe567de083aab5ce152163f4d3)
namei: retry absolute symlink expansions from the native root
For a Linux ABI process, namei() resolves a path first under the ABI
root (compat.linux.emul_path) and, if that fails, restarts the walk
of the original path from the native root. Since 459ac3044b51 an
absolute symlink target found during the ABI pass stays under the
ABI root, so self-contained Linux userlands resolve their own
symlinks correctly (PR 289739); but when the target names a file
that exists only in the native namespace, the walk fails and the
restart cannot recover: it re-walks the original path, whose
ABI-visible prefix (the symlink itself) does not exist natively.
Casualties are the absolute symlinks planted under the emulator root
to integrate the host into the Linux namespace -- among them
linux-rl9-fontconfig's /compat/linux/etc/fonts ->
/usr/local/etc/fonts (Linux fontconfig cannot load its
configuration, degrading font matching to arbitrary results) and
similar links from linux-rl9-alsa-lib and linux-rl9-ca-certificates
-- and linprocfs' /proc/<pid>/exe, whose target is a host path:
[22 lines not shown]
sysconf: report a truncated keyword match list
snprintf(3) returns the length that would have been written, so an
ambiguous prefix can fill the match buffer with no sign that names
were cut off. Append " (truncated)" when that happens. Drop the
empty statement when scanning option arguments: only a separate
argument consumes the next argv entry.
Bump sysconf(8) to 2.2.1.
Suggested by: fuz
Reviewed by: fuz
Differential Revision: https://reviews.freebsd.org/D60815
LinuxKPI: account for delayed work cancelled after taskqueue dequeue
I encounter intermittent shutdown/restart hangs with i915/GuC and the
normal 34 ms scheduling-disable delay. Setting that delay to zero has
avoided the hang in my testing. This change fixes a reproducible
LinuxKPI cancellation-accounting defect that can leave the
corresponding context reference unreleased, rather than changing the
driver's delay.
Commit 79e290d96786 corrected the ordinary queued and already-executing
return values of cancel_delayed_work_sync(). There is still a gap
between native taskqueue dequeue and LinuxKPI callback ownership:
1. In sys/kern/subr_taskqueue.c, taskqueue_run_locked() removes the
task, clears ta_pending and sets tb_running before calling its
handler.
2. Before linux_work_fn() claims the callback,
linux_cancel_delayed_work_sync_int() atomically changes WORK_ST_TASK
to WORK_ST_IDLE.
[34 lines not shown]
powerpc: keep the VSX halves of the FPRs across back-to-back signals
grab_mcontext() only put the second halves of vs0-31 into the context
while the thread owned the VSX unit, but sigreturn(2) gives ownership
up so that the next use reloads the registers lazily. A signal that
arrives right after a sigreturn, like one the handler's mask was
holding back, got a context without them and its own sigreturn then
zeroed them in the PCB.
The halves saved in the PCB are current whenever the FP state is, since
VSX instructions can't run without PCB_VSX and save_fpu() stores them
in that case, so export them together with the FP registers.
Reviewed by: jhibbits
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D60754
sound: Remove unncessary locking in sysctl_hw_snd_hwvol_mixer()
The locking around strlcpy() was because of m->hwvol_mixer, but this is
just an int, so we don't need to lock in this case. Instead lock only
when m->hwvol_mixer is written.
While here, add parentheses around the returns.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59109
(cherry picked from commit 044ef293a8bbd057de3fb13ec97d3d0ee16462e4)
sound: Retire mixer_hwvol locked variants
Prior to 9a00e0b8ca56 ("snd_uaudio: Do not use snd_mixer->lock as
mixer_lock"), there was a need for mixer_hwvol_mute_locked() and
mixer_hwvol_step_locked(), because the unlocked variants would acquire
the lock, but uaudio_hid_rx_callback() would also hold the lock, so this
was a measure to avoid recursion on snd_mixer->lock. Now that
snd_uaudio(4) has a private mixer lock, the locked variants are not only
unnecessary, but wrong, because we now lock the private lock and not the
snd_mixer one, which is what mixer_hwvol_mute_locked() and
mixer_hwvol_step_locked() expect. Retire the locked variants and call
the regular functions instead.
The unlocked variants take the mixer lock, which is now the PCM lock,
and reach uaudio_mixer_ctl_set(), which takes mixer_lock. Calling them
straight from uaudio_hid_rx_callback() would therefore take mixer_lock
and the PCM lock in the opposite order to the mixer ioctl path, so
record what the HID report asked for and perform the volume change at
the end of the callback, with mixer_lock dropped. The USB stack allows a
[7 lines not shown]
sound: Use uint8_t instead of legacy u_char
No functional change intended.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
(cherry picked from commit 2793e5498dd9bceada62ebe38967d89180bd15f6)
sound: Do not set a recording source in mixer_uninit()
We currently set the recording source to SOUND_MIXER_MIC during mixer
deletion. Apart from the fact that this control might not be present on
all devices, it is unnecessary to do that, plus we already set all the
volumes to 0 in the mixer_set() call above.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59076
(cherry picked from commit 03b59d2e7df263ea5a8904e5593d14f6e3e0fbd8)
sound: Use snddev_info->lock in place of snd_mixer->lock
snd_mixer and snddev_info have a 1:1 relationship. Now that snd_mixer is
embedded into snddev_info, it makes even more sense for both to share
the PCM lock. The only exceptions to this are MIXER_TYPE_SECONDARY
mixers, which still retain a private lock (snd_mixer->priv_lock),
because they are attached to the device driver, and not snddev_info.
Only snd_emu10kx(4) uses a secondary mixer.
A side-effect of this is that the MIXER_SET_LOCK()/MIXER_SET_UNLOCK()
mess goes away. These macros were used in the mixer_set*() functions to
drop the mixer lock if the driver is Giant-locked and the function can
sleep inside MIXER_SET*() methods, and to avoid an LOR before locking
PCM to guard channel list traversal.
Since mixers now use the PCM lock, drop the channel lock in
chn_syncstate() before calling mix_get(), to avoid an LOR. These lines
were actually already commented out for years.
[5 lines not shown]
sound: Defer macio codec volume writes to a task
tumbler(4), snapper(4) and onyx(4) write the volume over I2C, and
iicbus_transfer() sleeps. This is why mixer_set() drops the mixer lock
around MIXER_SET() for non-MPSAFE drivers, relying on Giant to keep them
serialized.
Store the volume in the softc and let a task do the I2C write with no
lock held, so that the mixer method does not sleep at all. The lock
dropping for non-MPSAFE drivers will be removed in a follow-up patch.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59073
(cherry picked from commit b9761547077fb94e12c0bfa81f3b8b2b2df3c0bb)
sound: Embed mixer cdev in snd_mixer
The mixer cdev belongs to the mixer, not to the PCM device, so move it
from snddev_info->mixer_dev into a new snd_mixer->cdev field. snd_mixer
itself is now included in snddev_info.
Also add a MIXER_REGISTERED() macro similar to PCM_REGISTERED().
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59071
(cherry picked from commit a614c07ad4520c072f58aebee54d16d9b72837f5)
sound: Simplify how snd_mixer is fetched and how the cdev is created
The primary snd_mixer was reached by accessing the mixer cdev's si_drv1.
This is tedious and ugly, so store the mixer in snddev_info->mixer and
access it directly.
Additionally, create the cdev in a new mixer_make_dev() function (in
similar fashion to dsp_make_dev()) in pcm_register(), when everything is
initialized, instead of risking potential races because mixer_init()
(called before pcm_register()) used to create the cdev.
Also add some NULL checks in pcm_register(), to avoid creating a mixer
cdev when the driver (e.g., fdt/audio_soc.c) does not create a mixer in
the first place, and similarly in pcm_unregister().
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59070
(cherry picked from commit 221babdf9feb7e1c1c001a4be735400ca6fb12cb)
sound: Standardize mixer_init() call order
Device drivers call mixer_init() in a non-standard order - some before
pcm_init(), and some after pcm_register(). However, both approaches are
potentially risky, and logically weak, since pcm_register() is supposed
to be the function that finalizes sound(4) attach.
Standardize the call ordering by moving all mixer_init() calls after
pcm_init(). This is also necessary for a follow-up patch, which expects
pcm_init() to have run first and initialized the PCM lock.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D59069
(cherry picked from commit 13fcc9caaf968083254b92546e21dedb322a920b)
snd_uaudio: drop the default monitor level to 10%
As noted in the comment, some headsets with a hardware sidetone are
incredibly sensitive and emit immediate feedback upon attach with the
current system-wide default of 75%. Drop it down just for snd_uaudio(4)
to avoid incredibly unpleasant surprises.
MFC after: 3 days
Reviewed by: christos
Differential Revision: https://reviews.freebsd.org/D59199
(cherry picked from commit c3c6a6c7825ccc744afddba692820296f72ea53f)
libthr: Remove deadcode in join_common
The while loop previous can only be break when ret == ETIMEDOUT. They
never produce EBUSY. Remove the deadcode here.
Reviewed by: kib
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D60711
clntrdma.h: Add some fields to RDMA structures (glue for nfsclrdma.ko)
This patch adds some fields to NFS client side RDMA
structures and an additional argument to xprt_rdma_release_send().
This patch does not fix any semantics issue.
MFC after: 3 months
Fixes: 884ee8d6c9b4 ("nfscl: Add some glue for client side NFS over RDMA")
iwm: mask closed_rb_num to the RX ring size
iwm_notif_intr() reads hw = le16toh(sc->rxq.stat->closed_rb_num) & 0xfff and
loops while (sc->rxq.cur != hw) without masking hw to the ring size (512 entries
for 9000-series MQ RX, 256 for legacy). If the hardware reports a value at or
above the ring size, cur never equals hw: the loop walks stale ring entries
indefinitely and the write-pointer update uses a bogus index. Linux iwlwifi
masks the value (5eae443eb5e2) and OpenBSD has done the same since 9000-series
support was added (3287dca4fa10).
This was found while debugging an iwm crash on another BSD using the same
driver lineage (DragonFly, upstream bug 3449)
Locally tested:
* 7260, 9260, STA mode
PR: kern/299427
Submitted by: David Bidner <david at crap.solutions>
[2 lines not shown]
iwm: ensure NIC is alive during txq enable
I broke this in a previous commit. OpenBSD already has the NIC
nailed alive but FreeBSD's codebase currently does not.
Locally tested:
* 7260, 9260, STA mode
Fixes: 0a12ff65b9647a6e31471e5d27a8692b4adb6803
Differential Revision: https://reviews.freebsd.org/D60823
iwm: fix incorrect mutex / crash use during error detach path
My previous commit (b3ef4013a4) added a couple of lock assertions.
However, the detach assertion is wrong - if the driver hasn't
attached then detach needs to be a no-op and this includes
not touching a deinit'ed mutex.
So, move the mutex check and use until after the attached check.
This fixes the driver crash I saw when another bit of in-flight
work caused attach to fail, and thus iwm_detach() -> iwm_detach_local()
ended up trying to use a deinit'ed mutex, leading to a crash.
Fixes: b3ef4013a4fa75063930d0221a0bc50f95af0527
Differential Revision: https://reviews.freebsd.org/D60821
sysrc: Be quiet when changing values
Make it easier for the rc group to facilitate having an option to fully
boot muted (à la OmniOS) without resorting to /dev/null redirections.
Reviewed by: imp, dteske
Differential Revision: https://reviews.freebsd.org/D46120
linuxkpi: add uuid_t and helpers
linux/uuid.h has only the guid_t family. Add uuid_t, next to guid_t,
with uuid_equal(), uuid_copy(), import_uuid() and export_uuid(),
mirroring the guid_ versions.
Used by drm/virtio for dma-buf UUID export.
Signed-off-by: Denis Borovikov <denis.borovikov at gmail.com>
Reviewed by: wulf
Differential Revision: https://reviews.freebsd.org/D60199
linuxkpi: add pci_is_vga()
Returns true for a VGA-compatible display controller and for the
pre-PCI 2.0 VGA class (base 0x00, subclass 0x01), as Linux's
pci_is_vga() does. Used by drm/virtio to decide whether to remove
the firmware framebuffer on virtio-vga.
Signed-off-by: Denis Borovikov <denis.borovikov at gmail.com>
Reviewed by: wulf
Differential Revision: https://reviews.freebsd.org/D60200
linuxkpi: add strncpy_from_user()
Same semantics as Linux: returns the string length without the NUL,
count if the string was truncated, or -EFAULT. Implemented with
copyinstr(9). Unlike linux_copyin() it does not translate the remapped
ioctl argument window; its user, drm/virtio, passes a pointer taken
from the ioctl payload, so that is not needed.
Signed-off-by: Denis Borovikov <denis.borovikov at gmail.com>
Reviewed by: wulf
Differential Revision: https://reviews.freebsd.org/D60198
