[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 Christos Margiolis changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5d980fadf73df64a1e0eda40a93170ed76ce6f14 commit 5d980fadf73df64a1e0eda40a93170ed76ce6f14 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:17 + Commit: Christos Margiolis CommitDate: 2024-05-23 00:57:17 + sound: Handle unavailable devices in various OSS IOCTLs mixer(8)'s -a option is used to print information about all mixer devices in the system. To do this, it loops from 0 to mixer_get_nmixers(), and tries to open "/dev/mixer%d". However, this approach doesn't work when there are disabled/unregistered mixers in the system, or when an audio device simply doesn't have a mixer. mixer_get_nmixers() calls SNDCTL_SYSINFO and returns oss_sysinfo->nummixers, whose value is the number of currently _enabled_ mixers only. Taking the bug report mentioned below (277615) as an example, suppose a system with 8 mixer devices total, but 3 of them are either disabled or non-existent, which means they will not show up under /dev, meaning we have 5 enabled mixer devices, which is also what the value of oss_sysinfo->nummixers will be. What mixer(8) will do is loop from 0 to 5 (instead of 8), and start calling mixer_open() on /dev/mixer0, up to /dev/mixer4, and as is expected, the first call will fail right away, hence the error shown in the bug report. To fix this, modify oss_sysinfo->nummixers to hold the value of the maximum unit in the system, which, although not necessarily "correct", is more intuitive for applications that will want to use this value to loop through all mixer devices. Additionally, notify applications that a device is unavailable/unregistered instead of skipping it. The current implementations of SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO and SNDCTL_CARDINFO break applications that expect to get information about a device that is skipped. Related discussion can be found here: https://reviews.freebsd.org/D45135#1029526 It has to be noted, that other applications, apart from mixer(8), suffer from this. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45256 lib/libmixer/mixer.3 | 7 +- sys/dev/sound/pcm/dsp.c | 23 +- sys/dev/sound/pcm/mixer.c | 201 -- sys/dev/sound/pcm/mixer.h | 2 - sys/dev/sound/pcm/sound.c | 41 ++ 5 files changed, 155 insertions(+), 119 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 277615] /usr/sbin/mixer -a does not display all mixer devices if /dev/mixer0 happens to not exist.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277615 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0e80798518be673bdad7245b627cb5bd7ec0 commit 0e80798518be673bdad7245b627cb5bd7ec0 Author: Christos Margiolis AuthorDate: 2024-05-23 00:57:25 + Commit: Christos Margiolis CommitDate: 2024-05-23 00:57:25 + mixer(8): Ignore mixer_open() failures for the -a option The most likely reason mixer_open() will fail is because either the device doesn't exist, or because it is disabled, so there is not reason to kill the application. Instead, continue and print the rest of the enabled mixers. PR: 277615 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45151 usr.sbin/mixer/mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=07b7dec1fe4296cdf470013087180a80a0d4a2cf commit 07b7dec1fe4296cdf470013087180a80a0d4a2cf Author: Konstantin Belousov AuthorDate: 2024-05-13 17:17:47 + Commit: Konstantin Belousov CommitDate: 2024-05-22 23:47:23 + SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information PR: 278949 (cherry picked from commit 87a156527563d0728bff355093e26943da3d7fad) sys/kern/sysv_msg.c | 34 ++ sys/kern/sysv_sem.c | 33 + sys/kern/sysv_shm.c | 36 sys/sys/msg.h | 3 +++ sys/sys/sem.h | 3 +++ sys/sys/shm.h | 2 ++ 6 files changed, 111 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265311] silly mount() arguments with MNT_UPDATE and MNT_UNION can cause kernel page-fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265311 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2a2f2f59132ad365203c5deb8ed16202a78585c1 commit 2a2f2f59132ad365203c5deb8ed16202a78585c1 Author: Konstantin Belousov AuthorDate: 2024-05-15 09:54:49 + Commit: Konstantin Belousov CommitDate: 2024-05-22 23:47:23 + vfs_domount_update(): postpone setting MNT_UNION until VFS_MOUNT() is done PR: 265311 (cherry picked from commit 21ccdb4119afdfdfeaa80e9c8514171c65b35862) sys/kern/vfs_mount.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278949] sysv IPC sysctl's behave differently for 32-bit on 64bits hosts
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278949 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b76674a73988eb708bdb53e11c5c54e8488b33a1 commit b76674a73988eb708bdb53e11c5c54e8488b33a1 Author: Konstantin Belousov AuthorDate: 2024-05-13 17:17:47 + Commit: Konstantin Belousov CommitDate: 2024-05-23 00:26:44 + SysV IPC: provide in-kernel helpers to obtain ipcs(8)-like information PR: 278949 (cherry picked from commit 87a156527563d0728bff355093e26943da3d7fad) sys/kern/sysv_msg.c | 34 ++ sys/kern/sysv_sem.c | 33 + sys/kern/sysv_shm.c | 36 sys/sys/msg.h | 3 +++ sys/sys/sem.h | 3 +++ sys/sys/shm.h | 2 ++ 6 files changed, 111 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265311] silly mount() arguments with MNT_UPDATE and MNT_UNION can cause kernel page-fault
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265311 --- Comment #2 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=625a622cc6511e250470ee3f84a8553c7c734de6 commit 625a622cc6511e250470ee3f84a8553c7c734de6 Author: Konstantin Belousov AuthorDate: 2024-05-15 09:54:49 + Commit: Konstantin Belousov CommitDate: 2024-05-23 00:26:43 + vfs_domount_update(): postpone setting MNT_UNION until VFS_MOUNT() is done PR: 265311 (cherry picked from commit 21ccdb4119afdfdfeaa80e9c8514171c65b35862) sys/kern/vfs_mount.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" command displays different results depending on use of -e option (closing new line)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric Vermetten changed: What|Removed |Added CC||ericvermet...@online.nl --- Comment #2 from Eric Vermetten --- In addition to previous comment: sed '/1/a\ -new line- ' behaviour, is mentioned in: sed & awk, 2nd edition; Arnold Robbin, Dale Dougherty at the "Command Summary for sed": " a [address]a\ text Append text following each line matched by address. If text goes over more than one line, newlines must be "hidden" by preceding them with a backslash. The text will be terminated by the first newline that is not hidden in this way. The text is not available in the pattern space and subsequent commands cannot be applied to it. The results of this command are sent to standard output when the list of editing commands is finished, regardless of what happens to the current line in the pattern space. " -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278936] mqueuefs: Crashes when removing queue as user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278936 Konstantin Belousov changed: What|Removed |Added CC||k...@freebsd.org --- Comment #5 from Konstantin Belousov --- https://reviews.freebsd.org/D45305 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] killpg(): Forking fast leads to livelock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Michael Gmelin changed: What|Removed |Added Severity|Affects Some People |Affects Many People Summary|logger: Forking many logger |killpg(): Forking fast |executables at once renders |leads to livelock |machine unresponsive| Component|bin |kern -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279231] wefwfeweffewwef
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279231 Li-Wen Hsu changed: What|Removed |Added Product|Base System |Other Version|15.0-CURRENT|unspecified Assignee|b...@freebsd.org|bugmeis...@freebsd.org Status|New |Closed Resolution|--- |Not A Bug CC||lw...@freebsd.org Component|gnu |Spam -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279231] wefwfeweffewwef
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279231 Bug ID: 279231 Summary: wefwfeweffewwef Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: gnu Assignee: b...@freebsd.org Reporter: fej...@tuta.io My life done I'm done with my life I just want to quit it all I can't get a job I'm sad I have no life I have no friends I have no hope I'm emotionless I'm worthless -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279227] csplit: handlesig is not async-signal-safe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279227 Dag-Erling Smørgrav changed: What|Removed |Added CC||d...@freebsd.org --- Comment #1 from Dag-Erling Smørgrav --- yeah the comment is wrong, it is no safer on FreeBSD than on any other *nix, but just like on any other *nix it will "appear" to work fine until you manage to trigger a signal at just the wrong time. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279227] csplit: handlesig is not async-signal-safe
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279227 Bug ID: 279227 Summary: csplit: handlesig is not async-signal-safe Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: kev...@freebsd.org handlesig calls cleanup(), which is itself not async-signal-safe if `doclean != 0` as it wants to use `snprintf` -- while it notes that it "appears" to be safe on FreeBSD, we should strive to be correct here. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279226] sort(1) can deadlock with poorly timed signal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279226 Bug ID: 279226 Summary: sort(1) can deadlock with poorly timed signal Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: kev...@freebsd.org sort(1) has a semapahore to protect the tmp file list, and it catches numerous signals to trigger tmp cleanup before bailing out. If we receive a signal while tmp_files_sem is held, we can easily deadlock sort(1) as the signal handler tries to take it again. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279225] pfctl(8) displays the name of the anchors incompletely
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279225 Bug ID: 279225 Summary: pfctl(8) displays the name of the anchors incompletely Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: dt...@disroot.org Description: When pfctl(8) is used to display anchors or to display NAT rules, the name of the anchors is displayed incompletely compared to 14.0-RELEASE. This results in programs failing when they depends on the output of pfctl(8) [1]. [1] https://github.com/DtxdF/AppJail/issues/10 Steps to reproduce this issue: 15.0-CURRENT: ``` # freebsd-version 15.0-CURRENT # pfctl -sn nat-anchor "appjail" all nat-anchor "appjail" all rdr-anchor "appjail" all # pfctl -sA appjail-nat appjail-rdr ``` 14.0-RELEASE: ``` # freebsd-version 14.0-RELEASE-p6 # pfctl -sn nat-anchor "appjail-nat/jail/*" all nat-anchor "appjail-nat/network/*" all rdr-anchor "appjail-rdr/*" all # pfctl -sA appjail-nat appjail-rdr ``` Tested on: * 14.0-RELEASE-p6 * 15.0-CURRENT Notes: * I have used `FreeBSD-15.0-CURRENT-amd64-20240516-d7adf3b47a05-270169-bootonly.iso` install FreeBSD on bhyve using vm-bhyve. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 241697] i915kms: Kernel panic loading module on custom kernel w/ MAXCPU < 256 (Invalid CPU in callout 256)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2792 ||24 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 Mark Linimon changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2416 ||97 Keywords||crash -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279224] [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279224 Bug ID: 279224 Summary: [panic] Loading i915kms from drm-61-kmod crashes if kernel was compiled with VT_MAXWINDOWS or SC_NO_CUTPASTE Product: Base System Version: 14.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: m...@fbsd2.e4m.org [If this is considered to be a ports issue feel free to modify the PR] 14.0-STABLE and 14.1-BETA as of today need drm-61-kmod (instead of drm-515-kmod as in earlier versions). Loading i915kms if the kernel had been built with either VT_MAXWINDOWS or SC_NO_CUTPASTE makes the system crash. Maybe this is something similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241697 which had hit me as well... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" command displays different results depending on use of -e option (closing new line)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric changed: What|Removed |Added Summary|sed - "a\" comand displays |sed - "a\" command displays |different results depending |different results depending |on use of -e option |on use of -e option ||(closing new line) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Eric changed: What|Removed |Added Version|14.0-RELEASE|13.3-RELEASE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 --- Comment #1 from Eric --- Using 13.3-RELEASE and "pkg install gsed" (version 4.9). For the a\ command of sed(1), whether or not specifying the -e option, produces different results. sed ' ... ' (without the -e option) seems to be in error. $ cat t 1 2 $ cat sed-add.sh #!/bin/sh sed '/1/a\ -new line-' > sed -e '... '\n" sed -e '/1/a\ -new line-' > sed -e ' ... ' 1 -new line- 2 Using variants with double quotes, as in: sed "/1/a\\ -new line-" https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html but the behaviour of sed -e ' ... ' seems the correct one. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279223] sed - "a\" comand displays different results depending on use of -e option
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279223 Bug ID: 279223 Summary: sed - "a\" comand displays different results depending on use of -e option Product: Base System Version: 14.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: erichans...@gmail.com test -- You are receiving this mail because: You are the assignee for the bug.
[Bug 146031] [snd_hda] race condition when kldunload snd_hda sound called
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146031 --- Comment #10 from Christos Margiolis --- I am not sure if this recent commit [1] is related to this issue, but I wasn't able to reproduce this bug on 14.0-RELEASE. I think it's better to close this. [1] https://cgit.freebsd.org/src/commit/?id=bed0b2146faa2e9a445d9f9196c7b46f50034631 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 146031] [snd_hda] race condition when kldunload snd_hda sound called
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146031 Enji Cooper changed: What|Removed |Added Status|Open|Closed Resolution|--- |Overcome By Events --- Comment #9 from Enji Cooper --- I no longer have access to this system and I don’t currently run any FreeBSD desktops or laptops with sound enabled on them. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266142] SNDSTIOC_ADD_USER_DEVS ioctl on /dev/sndstat passes unchecked size from user to malloc() -> potential crash
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266142 --- Comment #5 from commit-h...@freebsd.org --- A commit in branch releng/14.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=18f80d6d463495703f9eb2ccfd92bae93c7889a3 commit 18f80d6d463495703f9eb2ccfd92bae93c7889a3 Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:28 + Commit: Christos Margiolis CommitDate: 2024-05-22 13:22:26 + sound: Check user-supplied size passed to SNDSTIOC_ADD_USER_DEVS* SNDSTIOC_ADD_USER_DEVS* expects a user-supplied sndstioc_nv_arg->nbytes, however we currently do not check whether this size is actually valid, which results in a panic when SNDSTIOC_ADD_USER_DEVS* is called with an invalid size. sndstat_add_user_devs() calls sndstat_unpack_user_nvlbuf(), which then calls malloc() with that size. PR: 266142 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:brooks Differential Revision: https://reviews.freebsd.org/D45236 (cherry picked from commit 074d337ad618f9cc2a1d5ab18b484928e57bd72b) (cherry picked from commit 5830a00c2c5485ec17900558e4f29c459c6a1f3e) Approved by:re (cperciva) sys/dev/sound/pcm/sndstat.c | 5 + sys/sys/sndstat.h | 5 + 2 files changed, 10 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 266144] bug in sndstat_unpack_user_nvlbuf()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266144 --- Comment #4 from commit-h...@freebsd.org --- A commit in branch releng/14.1 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8d3f96bd85c9519cef76d0727b00082354a2134b commit 8d3f96bd85c9519cef76d0727b00082354a2134b Author: Christos Margiolis AuthorDate: 2024-05-20 14:18:33 + Commit: Christos Margiolis CommitDate: 2024-05-22 13:22:40 + sound: Correctly check nvlist_unpack() error The current check is never false and if nvlist_unpack() fails, we might panic later down the road. PR: 266144 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by:dev_submerge.ch, emaste Differential Revision: https://reviews.freebsd.org/D45237 (cherry picked from commit 64f4e2db6d19d8ab520903a197fcaa8cc7ab9f9a) (cherry picked from commit 45feaa73c68011bbba647d1eb6f86a166a0453e9) Approved by:re (cperciva) sys/dev/sound/pcm/sndstat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 Michael Gmelin changed: What|Removed |Added Flags||mfc-stable13?, ||needs_errata? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279052] Request account removal
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279052 Mark Linimon changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You reported the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203 --- Comment #2 from Michael Gmelin --- Cherry-picking this commit fixes the issue for me: commit 7a70f17ac4bd64dc1a5020f963ba4380cf37b7e5 Author: Konstantin Belousov Date: Fri Jul 7 20:19:33 2023 +0300 killpg(): more carefully avoid LoR otherwise we could end up with the livelock. When pg_killsx trylock failed, ensure that we do wait for lock availability before retry. Reported and tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week -- You are receiving this mail because: You are the assignee for the bug.
[Bug 279203] logger: Forking many logger executables at once renders machine unresponsive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279203
Michael Gmelin changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #1 from Michael Gmelin ---
This only seems to affect 13.3 and 13-STABLE after
https://cgit.freebsd.org/src/commit/?h=stable/13=2b0cd3b552942c642a84f8e224b989c02d97125d
("killpg(2): close a race with fork(2), part1").
--
You are receiving this mail because:
You are the assignee for the bug.
