When saving a coredump, savecore(8) maintains .last symlinks for the
info and vmcore artifacts, but not for the crashinfo text report.
Make crashinfo(8) create the link, pointing at the current
core.txt.<bounds> file.
This makes /var/crash/core.txt.last track the same core dump as
info.last and vmcore.last.
[mhorne: I tweaked the submission, such that the link will be created as
soon as the core.txt.X file is generated; not only after a successful
report has been written.]
Signed-off-by: Ricardo Branco <rbranco@suse.de>
Reviewed by: mhorne
MFC after: 1 week
Pull Request: https://github.com/freebsd/freebsd-src/pull/2199
This particular calls swaps the samples and maxchan arguments, which can
cause a buffer overflow in p_ch_chain if maxchan exceeds its bounds
(VMAX_CHAN).
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: emaste
Accessing usb_xfer_queue requires bus lock, we added this missing lock
in here to prevent racing issue.
Reviewed by: adrian
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57293
Introduce pcm_hotswap(), which is responsible for sending devctl
SND/CONN notifications.
There are two user-visible improvements with this patch:
First, in pcm_unregister(), instead of just sending a SND/CONN/NODEV
notification when all devices have detached, we also switch to the new
default device if the previously default one has detached, but there are
more left.
Second, in pcm_register(), if the device happens to also be the new
default device, we hot-swap to it. Additionally, if hw.snd.default_auto
is set to 2, then we will essentially be hot-swapping to the newest
attached device.
The latter is especially useful for laptops like the Framework 16, which
comes with a built-in snd_hda(4) speaker-microphone-only device, and
headphones can work with the Framework Audio Expansion Card, which does
not extend the snd_hda(4) device, but is in fact a separate
snd_uaudio(4) device. To achieve automatic audio redirection between
headphones and speakers in this case, there has to be a way to switch
between different devices. The way the Audio Expansion Card works is by
having snd_uaudio(4) attach to it when the headphones are plugged, and
detach when unplugged, so this patch, along with hw.snd.default_auto=2,
can pick up those attach events and switch automatically. Combined with
the pcm_unregister() update, it becomes possible to switch back and
forth between headphones and speakers.
While here, be more robust and lock around snd_unit reads.
In collaboration with: jrm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Instead of throwing errors from the programs that use it, print a
warning if the file does not exist.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: 0mp, jrm
Pull-Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/33
Sometimes virtual_oss processes do not exit immediatelly. If we do not
wait for the processes to fully exit before returning from
virtual_oss_stop(), then the service restart operation might call
virtual_oss_start() too early and fail, because it will think the
service wasn't stopped and is still running.
Reported by: jrm
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: 0mp, jrm
Pull-Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/33
They will now be part of /etc/defaults/rc.conf and be accessible by
sysrc(8).
Fixes: 70e27ecba5 ("virtual_oss: Introduce virtual_oss_default_control_device rc variable")
PR: 295560
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: 0mp, jrm
Pull-Reqeust: https://ron-dev.freebsd.org/FreeBSD/src/pulls/33
This doesn't really matter, as we trust that the installer tarballs are
not malicious, but it doesn't hurt to set these flags.
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li, and Ke Xu from Tsinghua University using GLM-5.1 from Z.ai
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57274
This section would be previously locked by sound(4)'s mixer lock (see
e87654db5a ("snd_uaudio: Stop using mixer_get_lock()")), but
snd_uaudio(4) no longer uses it. This particular code path was missed
during testing, because my sound card does not reach it.
Fixes: 9a00e0b8ca ("snd_uaudio: Do not use snd_mixer->lock as mixer_lock")
Reported by: netchild
Tested by: netchild
Sponsored by: The FreeBSD Foundation
MFC after: 6 days
The MD function with MI interface to provide a way to read arbitrary
(canonical) KVA. amd64 only for now.
Reviewed by: markj
Tested by: aokblast
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D49566
The ACL tests use UIDs and GIDs 41 through 49 and expect them to be
unassigned. Since GID 43 is now assigned to the audio group, some
tests have begun to fail.
While here, also fix a benign Perl syntax issue in the test runner.
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57297
The timestamp_origin test sends an ICMP Timestamp Request (ping -Mt) and parses
the tso/tsr fields out of the reply.
When the sysctl net.inet.icmp.tstamprepl is 0, the kernel silently drops the
request, ping receives no reply, and the sed extraction yields an empty $tso.
The test then fails inside atf_check test -n "$tso" with the unhelpful message
Approved by: maxim
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D57287
The only possible way to exercise in_pcbrehash() is to bind(2) and then
connect(2). The second branch was a dead code since fdb987bebd.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D57241
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
Sponsored by: Fudo Security
Differential Revision: https://reviews.freebsd.org/D57271
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
Previously this was using CAM_PRIORITY_NONE which tripped over the
assertion added in b4b166b8c4.
PR: 293076
Reported by: Ken J. Thomson <thomsonk@yandex.com>
Reviewed by: imp
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D56995
Commit 969876fcee 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
6acc7afa34) 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@yandex.com>
Fixes: 969876fcee ("ctld: parse config file independently of getting kernel info")
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D57093
- 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.
NB: The kernel_port class handles CTL ports that already existed
before ctld started including existing ioctl ports, whereas the
ioctl_port class handles ioctl ports that are created and completely
managed by ctld. This was true before this change but is perhaps more
obvious after this change.
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D57092
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
INTRNG mask/unmask sequence.
2. When the GPIO IRQ filter dispatches a pin and finds no consumer
registered, mask the pin at the controller (INTMASK=1, INTEN=0)
before continuing. Level-triggered sources keep asserting until
acked, so a single stuck pin used to flood the console with
thousands of "Interrupt pin=N unhandled" lines per second. The
mask survives until something re-attaches and re-enables the IRQ
via the standard pic_enable_intr path.
Affects all level-triggered IRQs on Rockchip GPIO banks; edge-
triggered IRQs were already self-acking and unaffected.
Signed-off-by: Kyle Crenshaw <B1nc0d3x@gmail.com>
Reviewed by: mhorne
MFC after: 2 weeks
Pull Request: https://github.com/freebsd/freebsd-src/pull/2197
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@isrc.iscas.ac.cn>
Reviewed by: mhorne
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2241
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
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: 1092ec8b33 ("kern: Introduce RLIMIT_VMM")
Fixes: 53af2026f2 ("limits: Unbreak after RLIMIT_VMM addition")
Reviewed by: bnovkov
Differential Revision: https://reviews.freebsd.org/D57265
I am not sure why this hack was needed, but the size should be
sizeof(struct snd_mixer). Unfortunately, we have to expose snd_mixer,
but it should be better than relying on a hack.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
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
These functions are called from sound(4) through MIXER_SET() in
mixer_set(), but nothing mixer-related is used or needs to be locked in
these cases.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
There is no reason to lock snd_mixer->lock here, since the only thing we
are doing with snd_mixer is to call mix_getdevinfo() and mix_get_dev(),
which are one-line getters, which are needed to eventually call
uaudio_get_child_index_by_dev().
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
In similar fashion to c234740c9d ("snd_uaudio: Do not use
pcm_channel->lock to protect uaudio_chan"), stop this layering
violation, and introduce a snd_uaudio(4)-internal mixer_lock.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Pull Request: https://ron-dev.freebsd.org/FreeBSD/src/pulls/18
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
Ricardo Branco