This function never succeeds when it is not called from the same process
that has opened the file descriptor (e.g., mixer(8)). The reason is that
the CHN_FOREACH() loop tries to match the pid of each channel with the
pid of the process performing the ioctl, which will not be the same,
unless it's the same process that both opened the channel and performed
the ioctl.
In the case that the same process opens the channels and performs the
ioctl, however, we still do not need to worry, because mixer_ioctl_cmd()
essentially does the same thing anyway. Additionally, this scenario
should be quite rare, given that most applications do not open both
/dev/dsp* and /dev/mixer*, and in fact, it is actively encouraged by the
official OSSv4 specification not to do that.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
Even though harmless, it is not really useful, as there is essentially
only one allocation with M_MIXER.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
It wasn't documented in the first place, but it is easier to just use
the sysctl.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
The SD_F_EQ_ENABLED does the same thing, and is actually what we test
against in order to create the EQ feeder.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
We can do this more efficiently by just using the SD_F_EQ* flags. In
fact, the dev.pcm.%d.eq handler will (un)set SD_F_EQ_ENABLED and this is
what we actually test with when choosing to creating the EQ feeder or
not, so setting the state to FEEDEQ_DISABLE does not really an effect in
the first place.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
In effect, this is the same as the disable state. There is a comment
that says the bypass state skips EQ altogether, which is what the
disable should be. The disable state according to the comment disables
EQ but keeps the EQ preamp (dev.pcm.%d.eq_preamp), however after testing
it seems that the preamp does not really take effect, because with EQ
disabled, feeder_eq is non existent, so we never execute any EQ code in
the first place.
Make things simpler and clearer and have 2 states; enable and disable,
and do what they should do intuitively.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
The dev.pcm.%d.eq* sysctls and mixer "bass" and "treble" controls are
exposed only if hint.pcm.%d.eq is set. However, there is no good reason
why we shouldn't at least expose the controls, and let the user
enable/disable/bypass equalization through the sysctl.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/15
On a copy-on-write, copy the memory tags from the source pages to the
destination pages so the forked process can continue to use MTE.
Reviewed by: andrew
Sponsored by: Arm Ltd
Signed-off-by: Harry Moulton <harry.moulton@arm.com>
Differential Revision: https://reviews.freebsd.org/D55955
To track which pages have MTE tags. Add a flag field to md_page. We
can then use this in MD code to mark which pages have MTE tags.
Reviewed by: andrew
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D55954
We need to store some extra information about a page, e.g. the state of
the MTE tags. Add a MD flags field to each page.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D55953
When entering the kernel from userspace we need to check for MTE tag
failures when using asynchronous MTE. This is done by checking if either
tag fault check types that have asynchronous checks are enabled, and
if so check the register the result is stored. It then sets a flag the
kernel can later use to raise a signal.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D55952
Add the same group of functions we use to manage pointer authentication
in userspace threads.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D55951
When MTE is enabled we will use the DMAP to manage tags. To be able to
read/write them we need to change the memory attribute to
VM_MEMATTR_TAGGED.
Support changing the DMAP memory type to values known to have
equivalent cache properties.
Sponsored by: Arm Ltd
Differential Revision: https://reviews.freebsd.org/D55949
Similar to arm64, riscv's pcb embeds a copy of the floating point
registers and is too large to store directly in struct mdthread as is
done on amd64. Instead, use a separate UMA zone for pcbs. riscv's
floating point state is not as large as arm64's, so its pcb is also
somewhat smaller and a single 4k page can hold 6 pcbs.
Reviewed by: kib, jrtc27
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
This is similar to commit 5e921ff49e
which moved the pcb for amd64, but a bit different. arm64's pcb is
much larger (over 1KB!) than amd64's since it still embeds FP
registers. Moving the pcb out of the kstack frees up that much
additional kstack space. Unlike amd64 however, embedding the pcb in
struct mdthread is not practical as the resulting struct thread would
grow such that UMA would now store 1 thread per 4k page instead of 2
threads per page. By using a separate UMA zone for pcbs, 2 struct
threads can continue to fit in a single 4k page, and 3 pcbs can fit in
another 4k page.
Reviewed by: kib, jrtc27, andrew
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
Previously, the cpu_thread_alloc callback was invoked each time a
kernel stack was allocated for a thread. This included thread
creation, but it was also invoked if a recycled thread had to allocate
a new kstack. This means that cpu_thread_alloc could be called
multiple times for a single thread, but cpu_thread_free is only called
once. Not only that, but the cpu_thread_alloc callback can't tell if
it is being invoked on a new thread object, or a recycled thread.
Calling *_alloc multiple times on an object is also atypical for
kernel APIs.
As a result of this confusion, amd64 was potentially leaking an XSAVE
buffer each time a new kstack was allocated for an existing thread,
since cpu_thread_alloc for amd64 always allocated a new XSAVE buffer.
In practice, this edge case is probably rare. A process object needs
to be recycled where either the new or old process is a kernel process
with a non-default kernel stack size.
Nevertheless, to ease the confusion, redefine cpu_thread_alloc to only
be called once when a new thread is allocated. The new callback,
cpu_thread_new_kstack is invoked each time a kstack is allocated for a
thread, including both at thread creation time and if a recycled
thread allocates a new kstack. The new callback should set any fields
whose value is dependent on td_kstack (e.g. the user frame in
td_frame, or td_pcb if the PCB is allocated on the kstack).
Reviewed by: kib, andrew (arm changes)
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
If XSAVE is being used, the XSAVE header will be overwritten either by
copying it from the parent thread in copy_thread for user threads, or
by a fresh copy from fpu/npx_initialstate on the first use of the FPU
for kernel threads.
Reviewed by: kib
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
This used to be needed to initialize the pcb pointer when the pcb was
allocated on the kstack.
Reviewed by: kib
Sponsored by: AFRL, DARPA
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
All other paths that return from the kernel to userspace pop the user
trapframe off of the kernel stack pointer before returning to
userspace in restore_registers. fork_trampoline was missing this, so
all of the user faults after fork pushed another trapframe leaving a
trapframe's worth of wasted space on the kstack.
This would be fatal after a future change to remove duplicate
initialization of td_frame in cpu_fork() as without this fix each time
a thread was recycled it would "lose" another trapframe's worth of
space.
Reviewed by: kib, andrew
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/23
When libarchive is compiled with FreeBSD's native iconv instead of
libiconv, as happens with libarchive in the base system, we need to
configure iconv(3) to handle invalid sequences by returning -1, as
iconv_strncat_in_locale() assumes GNU iconv semantics.
This corresponds to upstream PR 3056.
PR: 294577
MFC after: 1 week
Ensure that the boot.config file gets an entry in the metalog by
tgt_touch()ing it. If a file is not present in the metalog, it gets
excluded from the final image when using "-U" (unprivileged builds).
MFC after: 2 weeks
The order of the flags matter in makefs(8). The -t (type) flag must come
before the -o (options) flag; otherwise, the options are reset.
Move the -t flag before the -o flag and remove the shim function
_xxx_adjust_code_size() that was created to align to the default makefs
FFS values.
It effectively prevented us from generating NanoBSD images using
unprivileged builds with the partitions internally aligned as intended.
Reviewed by: senguptaangshuman17_gmail.com, imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57226
Switch from the min/max size flag (-s) to the round-up flag (-R) when
invoking makefs(8).
Because the partition sizes passed to nano_makefs have already been
rounded up by calculate_partitioning(), using -s can cause makefs to try
to perform sizing adjustments that usually result in failures.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57225
mkimg(8) parses sizes using expand_number(3). It is an error to use "b"
as a suffix. This is the result of a confusion with makefs(8), which
uses NetBSD's strsuftoll(3).
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57224
When building an unprivileged NanoBSD image, explicitly set the desired
image size, by passing --capacity to mkimg in bytes, and the logical
sector size (-S) to 512 bytes.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57222
Ensure the primary and secondary code partitions start at a proper track
boundary by applying a NANO_SECTS offset in bytes.
While track-boundary alignment is largely obsolete on modern storage,
this change maintains compatibility with current images (legacy). A
future commit will transition to 1 MiB alignment boundaries.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57221
The code slice size (CODE_SIZE) includes 16 sectors reserved for disk
metadata (see bsdlabel(8) offset). Subtract these 16 sectors from the
total size passed to nano_makefs.
This prevents the generated filesystem from consuming the entire slice
allocation, ensuring there is enough space for the metadata without
overflowing the partition boundary.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57220
Use the calculated (rounded up) cfg and data sizes from the
_.partitioning file, instead of consuming them directly from the global
variables. We obtain the size of the cfg and data slices by explicitly
searching for index 3 and 4 respectively in the _.partitioning file.
This ensures that the final image has the rounded-up sizes, and not the
raw sizes.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57219
Previously the code was assumed to be on the on the first line of the
_.partitioning file. Instead, explicitly look up the size by its
partition index to make the parsing order-independent.
The _.partitioning file:
1. First column: starting sector.
2. Second column: size in 512-byte sectors.
3. Third column: partition index.
Get the code size by explicitly selecting when the partition index is 1.
Reviewed by: imp
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D57216
Christos Margiolis