[Bug 267671] [libc] Remove unnecessary printf to stderr in stdlib/cxa_thread_atexit_impl.c

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267671

--- Comment #3 from Rainer Hurling  ---
(In reply to David Chisnall from comment #2)

Thanks for the reply. 

In my case, the error messages occur when using my graphics/qgis port. This
application is very complex and uses extensively Qt5 functionalities. 

Unfortunately, since I am not a coder myself, I have no approach on how to
track down the root cause and thus the potential security issue. So far I can't
find any systematics for the occurrence of the error message. The messages
occur every now and then while working in QGIS, but always exactly 27 times
when exiting QGIS. It is always exactly the same message, even after a new call
of QGIS:

__cxa_thread_call_dtors: dtr 0x82dd12f90 from unloaded dso, skipping

I could use a little help to generate more information about this error.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274208] man.freebsd.org unexpected justification (alignment) of SYNOPSIS texts

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274208

Bug ID: 274208
   Summary: man.freebsd.org unexpected justification (alignment)
of SYNOPSIS texts
   Product: Documentation
   Version: Latest
  Hardware: Any
   URL: https://man.freebsd.org/cgi/man.cgi?query=pkg&sektion=
8&manpath=freebsd-ports
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: grahamper...@gmail.com
CC: d...@freebsd.org
Depends on: 273903

Tentatively blocked by bug 273903. 

Compare these two captures, for example:






Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273903
[Bug 273903] groff 1.23.0 metabug
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273903] groff 1.23.0 metabug

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273903

Graham Perrin  changed:

   What|Removed |Added

 Blocks||274208


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274208
[Bug 274208] man.freebsd.org unexpected justification (alignment) of SYNOPSIS
texts
-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273903] groff 1.23.0 metabug

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273903

--- Comment #1 from Baptiste Daroussin  ---
feel free to take maintainership of groff, I don't really have time for it
anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 241872] ktrace sometimes doesn't record the name of the file supplied to the open(2) call

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241872

Dmitry Chagin  changed:

   What|Removed |Added

 CC||dcha...@freebsd.org

--- Comment #1 from Dmitry Chagin  ---
It looks fixed in 14.0

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273610] Panic (vm_page_assert_xbusied: page 0xfffffe0001beaed8 busy_lock 0xfffffffe not owned by me)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273610

--- Comment #6 from Mark Johnston  ---
(In reply to Graham Perrin from comment #5)
I'd guess so.  But you don't really need to boot them, you can just mount the
BE somewhere and either point kgdb at the kernel, or chroot into the BE.

At this point though I think it's not necessary anymore, I found a bug which
can cause this panic.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273610] Panic (vm_page_assert_xbusied: page 0xfffffe0001beaed8 busy_lock 0xfffffffe not owned by me)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273610

--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=e61568aeeec7667789e6c9d4837e074edecc990e

commit e61568aeeec7667789e6c9d4837e074edecc990e
Author: Mark Johnston 
AuthorDate: 2023-10-02 11:49:27 +
Commit: Mark Johnston 
CommitDate: 2023-10-02 11:49:52 +

swap_pager: Fix a race in swap_pager_swapoff_object()

When we disable swapping to a device, we scan the full VM object list
looking for objects with swap trie nodes that reference the device in
question.  The pages corresponding to those nodes are paged in.

While paging in, we drop the VM object lock.  Moreover, we do not hold a
reference for the object; swap_pager_swapoff_object() merely bumps the
paging-in-progress counter.  vm_object_terminate() waits for this
counter to drain before proceeding and freeing pages.

However, swap_pager_swapoff_object() decrements the counter before
re-acquiring the VM object lock, which means that vm_object_terminate()
can race to acquire the lock and free the pages.  Then,
swap_pager_swapoff_object() ends up unbusying a freed page.  Fix the
problem by acquiring the lock before waking up sleepers.

PR: 273610
Reported by:Graham Perrin 
Reviewed by:kib
MFC after:  1 week
Differential Revision:  https://reviews.freebsd.org/D42029

 sys/vm/swap_pager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273610] Panic (vm_page_assert_xbusied: page 0xfffffe0001beaed8 busy_lock 0xfffffffe not owned by me)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273610

Mark Johnston  changed:

   What|Removed |Added

 Status|Open|In Progress
   Assignee|b...@freebsd.org|ma...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org

--- Comment #6 from Mark Johnston  ---
Presumably the cause of the panic is that netdump_configure() doesn't check the
return value of ifunit_ref() for null?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

--- Comment #7 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=d94d07d58141dcff48f01c6b3e5a31de9d7a7938

commit d94d07d58141dcff48f01c6b3e5a31de9d7a7938
Author: Mark Johnston 
AuthorDate: 2023-10-02 12:08:20 +
Commit: Mark Johnston 
CommitDate: 2023-10-02 12:09:26 +

netdump: Check the return value of ifunit_ref()

We may fail to match if the specific interface doesn't exist or was
renamed.

PR: 273715
Reported by:grembo
MFC after:  1 week

 sys/netinet/netdump/netdump_client.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 248184] readlink("/proc/curproc/file") returns arbitrary correct name for programs with more than one link (name)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248184

Tobias Kortkamp  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #15 from Tobias Kortkamp  ---
I believe this has been fixed. Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273626] Memory leak in ioctl nvme passthrough commands

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273626

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Open

--- Comment #2 from Mark Johnston  ---
This looks right to me.  Warner, do you have any objections to committing this?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274191] There is no knob to disable git use on build system

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274191

--- Comment #3 from Ed Maste  ---
newvers.sh looks for a .git directory and does not invoke git if not found.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273953] panic: vfs_remount_ro: mp is not busied

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273953

Mark Johnston  changed:

   What|Removed |Added

 Status|Open|Closed
   Assignee|b...@freebsd.org|k...@freebsd.org
 Resolution|--- |FIXED
 CC||ma...@freebsd.org

--- Comment #6 from Mark Johnston  ---
I'll presume that the bug is fixed now.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274191] There is no knob to disable git use on build system

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274191

--- Comment #4 from Ivan Rozhuk  ---
(In reply to Ed Maste from comment #3)

I do not want workaround with renaming git binary or renaming .git dir, I want
NOGIT or similar knob start work.

Also "auto detect" features without on/off switch produces unpredictable
results, so REPRODUCIBLE_BUILD is not reproductable: newvers.sh give different
output on systems with .git+git and on systems without it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 272909] [14.0 CURRENT] panic: Bad link elm 0xfffff8018f003f70 next->prev != elm cpuid = 1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272909

Mark Johnston  changed:

   What|Removed |Added

 Status|New |Open
 CC||ma...@freebsd.org

--- Comment #1 from Mark Johnston  ---
Possibly related to
https://cgit.freebsd.org/src/commit/?id=2bd446d7f1a03fbf6d98ace4548f8793599f48fb
?

Does the panic occur on the latest main or 14.0 candidates?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 232978] /etc/rc.d/ntpdate - not removed with ntp

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232978

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
Note that it is also installed regardless of WITHOUT_NTP being set, and I
suspect this is true for many rc.d scripts.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

--- Comment #8 from Michael Gmelin  ---
(In reply to Mark Johnston from comment #6)

Hi,

Thank you for the fix.

I just checked, in 13.1 rcorder was:

  /etc/rc.d/sysctl
  /etc/rc.d/natd
  /etc/rc.d/dhclient
  /etc/rc.d/dumpon

while on 13.2 rcorder is:

  /etc/rc.d/sysctl
  /etc/rc.d/natd
  /etc/rc.d/dumpon
  /etc/rc.d/dhclient

So on 13.1, dumpon was called after interface renaming takes, while on 13.2,
device renaming happens after dumpon is started (which exposed the bug).

Without checking in more detail, this sounds like a plausible explanation.

It also means, that - even after applying the fix - it's not possible to have a
dumpon configuration in /etc/rc.conf that will work during runtime (service
dumpon start) and also on boot, in case a renamed interface is used. This seems
like something that would be worth addressing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 269568] strip(1) creates an executable which crashes in ld-elf.so.1

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269568

Ed Maste  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2588
   ||72

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

--- Comment #9 from Mark Johnston  ---
> So on 13.1, dumpon was called after interface renaming takes, while on 13.2, 
> device renaming happens after dumpon is started (which exposed the bug).

How did you come to that conclusion?  Does "dhclient" somehow cause interfaces
to be renamed?  That seems surprising given that your rc.conf doesn't enable
DHCP on anything.

> This seems like something that would be worth addressing.

Certainly.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

--- Comment #10 from Michael Gmelin  ---
(In reply to Mark Johnston from comment #9)

> How did you come to that conclusion?

By the art of baseless speculation.

I compared the actual 13.1 and 13.2 boot sequences, and on both the interfaces
are renamed after dumpon is called. So forget that.

I spent the time to actually read your patch the previous change that lead to
it, so this all makes sense now (Captain Obvious reiterating):

https://cgit.freebsd.org/src/commit/sys/netinet/netdump/netdump_client.c?id=38a36057ae56c8023878f3c3c2185bafc2896964

introduced a check if the device supports debugnet. This check couldn't deal
with non-existing interfaces, which is the bug you fixed.

Before the check was introduced, setting the renamed interface name was fine,
since at the point the panic I tested with happened - which is after device
renaming - it just worked(tm). If there was a panic between dumpon and device
renaming, netdump would have failed of course (but that's a rare thing to
happen).

Now with the check in place, it first crashed (due to the bug reported) and now
- with the fix - will not catch on, as an interfaces named "untrusted" cannot
be found.

I see various options how to resolve this:

1. Always allow using the physical device name (so it would somehow poke around
and find it)
2. Add a flag to dumpon (e.g., `-f` for force) to skip the device exists/device
supports debugnet check
3. Allow specifying multiple devices netdump_client to try when dumping
4. Determine based on the device name if it can exist early (feels wonky)

For my setup, 2. would be sufficient and easy to apply (as this means that all
I have to do to adapting my base rc.conf for a new host is modify the
ifconfig__name line in rc.conf). It would also be quite easy to
implement I assume (DIOCGKERNELDUMP would need to be extended though - unless
some encoding in one of the existing parameters is done, like "dumpon -s
192.168.1.1 -s 192.168.1.2 untrusted:nocheck"). Alternatively this could maybe
be handled using a sysctl(?).

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273626] Memory leak in ioctl nvme passthrough commands

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273626

--- Comment #3 from Warner Losh  ---
(In reply to Mark Johnston from comment #2)
This patch is correct. I'm likely going to be a while to commit it, so if you'd
like to add a 'Reviewed-by: imp' to the commit and go for it.
This should go into stable/14 and releng/14.0 too.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273626] Memory leak in ioctl nvme passthrough commands

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273626

--- Comment #4 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=7ea866eb14f8ec869a525442c03228b6701e1dab

commit 7ea866eb14f8ec869a525442c03228b6701e1dab
Author: David Sloan 
AuthorDate: 2023-09-07 16:22:21 +
Commit: Mark Johnston 
CommitDate: 2023-10-02 15:50:14 +

nvme: Fix memory leak in pt ioctl commands

When running nvme passthrough commands through the ioctl interface
memory is mapped with vmapbuf() but not unmapped. This results in leaked
memory whenever a process executes an nvme passthrough command with a
data buffer. This can be replicated with a simple c function (error
checks skipped for brevity):

void leak_memory(int nvme_ns_fd, uint16_t nblocks) {
struct nvme_pt_command pt = {
.cmd = {
.opc = NVME_OPC_READ,
.cdw12 = nblocks - 1,
},
.len = nblocks * 512, // Assumes devices with 512 byte lba
.is_read = 1, // Reads and writes should both trigger leak
}
void *buf;

posix_memalign(&buf, nblocks * 512);
pt.buf = buf;
ioctl(nvme_ns_fd, NVME_PASSTHROUGH_COMMAND, &pt);
free(buf);
}

Signed-off-by: David Sloan 

PR: 273626
Reviewed by:imp, markj
MFC after:  1 week

 sys/dev/nvme/nvme_ctrlr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273626] Memory leak in ioctl nvme passthrough commands

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273626

Mark Johnston  changed:

   What|Removed |Added

 Status|Open|In Progress
   Assignee|b...@freebsd.org|ma...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273715] dumpon: Kernel panic on boot when enabling dumpon over IP

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273715

--- Comment #11 from Zhenlei Huang  ---
A minimal snip to repeat this bug:

```
# dumpon -i 0 -c 192.168.255.3 -g 192.168.255.1 -s 192.168.255.1 nonexist
```

> I see various options how to resolve this:

> 1. Always allow using the physical device name (so it would somehow poke 
> around and find it)
> 2. Add a flag to dumpon (e.g., `-f` for force) to skip the device 
> exists/device supports debugnet check
> 3. Allow specifying multiple devices netdump_client to try when dumping
> 4. Determine based on the device name if it can exist early (feels wonky)

The `dumpon` start quite early, even before `FILESYSTEMS`. At that time `netif`
(interface renaming) has no chances to run.

I guess it is intended to let dumpon run as early as possible so that almost
all kernel panics can be caught rightly.

Well for netdump(4), if a pubkey is requested, then dumpon requires
`FILESYSTEMS`.

I guess we want to defer the setup of netdump(4), until `FILESYSTEMS` (probably
also `netif`) is/are ready.

Or we can split the rc.d/dumpon into `rc.d/dumpon` and `rc.d/netdump`.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273809] Thinkpad T430 headphones don't work

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273809

Captain_Lesbee_Ziner  changed:

   What|Removed |Added

 CC||theinnovativeadventurer@gma
   ||il.com

--- Comment #10 from Captain_Lesbee_Ziner  
---
Intro:
Hello there, I am a new user of FreeBSD coming from Windows 10. I don't know
much in this area, only started playing with installing open source operating
systems and multi-booting this year. 

Details:
Currently I am working on setting up my Thinkpad T430. I have Lubuntu, Windows
10, and FreeBSD 13.2 on it. My speakers work great, tested them last night, but
my headphones are not working right, that's why I am here. At first I thought I
had no sound, but every so often I thought I heard something, so ran mixer in
the shell and adjusted all the groups to 100:100. I could hear something. I was
using vlc to test the sound by playing a mp3 file so I played with different
output modules that it had listed, didn't change anything. So I boosted the
volume through vlc and I could hear the song I was playing faintly. I then
tried out the headphones in default lubuntu to make sure the jack and
headphones were good. Played a song in vlc, worked perfectly.

Summary:
Thought I would mention this since I am getting sound on a T430, but very low.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274223] scriptedpart utility fails refuses to generate an fstab file, making automated v14.0 installs impossible.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274223

Bug ID: 274223
   Summary: scriptedpart utility fails refuses to generate an
fstab file, making automated v14.0 installs
impossible.
   Product: Base System
   Version: 14.0-CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: la...@lavabitllc.com

Created attachment 245389
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=245389&action=edit
Error message when /mnt fills up.

The v14.0 installer has a broken version of the
/usr/libexec/bsdinstall/scriptedpart utility. It partitions the target disk
properly, but doesn't write the target disk layout to an fstab file, as it
should. Because of this, the '
'bsdinstall mount' step fails to mount the target disk onto the /mnt
mountpoint. Because the /mnt directory is setup as a tmpfs (with my configs),
the installer continues. It then either a) fails when the /mnt partition runs
out of space, or b) if the tmpfs is large enough, completes the install, only
to have it disappear when the VM reboots.

This issue was discovered with HBSD v14.0 and then confirmed using the FBSD
14.0 BETA4 and BETA1 installers. See these emails for more verbosity on the
subject.

https://groups.google.com/a/hardenedbsd.org/g/users/c/co6oSBfmdOE/m/0aBHQ54qAwAJ

https://groups.google.com/a/hardenedbsd.org/g/users/c/co6oSBfmdOE/m/yvs6JkQ9AwAJ

https://groups.google.com/a/hardenedbsd.org/g/users/c/co6oSBfmdOE/m/8xCnhSJAAwAJ

https://groups.google.com/a/hardenedbsd.org/g/users/c/co6oSBfmdOE/m/wL2mf8xOAwAJ

I've confirmed this bug on QEMU using the AMD64. The other hypervisor installs
(Vbox, Vmware, Hyper-V, etc) also failed, so I assume the bug isn't platform
specific, but I haven't pulled up the console on the systems to confirm.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274223] scriptedpart utility fails refuses to generate an fstab file, making automated v14.0 installs impossible.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274223

--- Comment #1 from Ladar Levison  ---
Created attachment 245390
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=245390&action=edit
Screenshot showing the empty fstab file, and partition table, confirming the
bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271727] login.conf(5), setusercontext(): Gap when setting a realtime-class priority

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271727

--- Comment #1 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=bd572be78436473a2ad4c1b78728b739c74ef238

commit bd572be78436473a2ad4c1b78728b739c74ef238
Author: Olivier Certner 
AuthorDate: 2023-05-25 07:10:27 +
Commit: Ed Maste 
CommitDate: 2023-10-02 20:38:03 +

setusercontext(): Fix gap when setting a realtime-class priority

The login.conf's "priority" capability allows to set priorities in the
idle or realtime classes in addition to the classical nice values (-20
to 20), through a natural extension where values greater than 20 put the
processes in the idle class (with priority adjusted within RTP_PRIO_MIN
and RTP_PRIO_MAX, 21 being converted to 0, 22 to 1, etc.) and values
lower than -20 put the process in the realtime class (with priority
adjusted within RTP_PRIO_MIN and RTP_PRIO_MAX, -21 being converted to
RTP_PRIO_MAX (31), -22 to 30, etc.).

Before this fix, in the latter case (realtime class), -21 was converted
to 30, and RTP_PRIO_MAX (31) could never be specified.

While here, change the priority computation for the idle-class case to
be symmetrical and use RTP_PRIO_MIN (in practice, this changes nothing
at all, since RTP_PRIO_MIN is 0; but this is the correct theoretical
formula, which would work as well with other values of RTP_PRIO_MIN).

PR: 271727
Reviewed by:imp, kib
MFC after:  2 weeks
Sponsored by:   Kumacom SAS
Differential Revision:  https://reviews.freebsd.org/D40339

 lib/libutil/login_class.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274226] No documentation for sendmsg/recvmsg ancilliary data.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274226

Bug ID: 274226
   Summary: No documentation for sendmsg/recvmsg ancilliary data.
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: pet...@freebsd.org
CC: d...@freebsd.org

recvmsg(2) and sendmsg(2) include provision for "ancillary data" via
msg_control and struct cmsghdr but there's no documentation on what cmsg_level
and cmsg_type mean or how to set them.  recvmsg(2) says "As an example, the
SO_TIMESTAMP socket option returns a reception timestamp for UDP packets" but
provides no information on how how to actually initialise the cmsghdr to do
that (the information is in getsockopt(2) but that isn't clear from the
recvmsg(2) man page).

In general, the recvmsg/sendmsg "ancillary data" manipulates similar data to
the setsockopt(2)/getsockopt(2) calls, but on a per-message basis, rather than
a per-connection/socket basis.  Unfortunately, there's not an exact 1:1
relationship between the functions and in some cases, the data length varies
between the two paths - e.g. the only documentation for IP_TOS is in ip(4) and
indicates that it takes an int argument (4 bytes), but 
https://cgit.freebsd.org/src/tree/sys/netinet/udp_usrreq.c#n1144 shows that
when used with sendmsg(2), the argument is a u_char (1 byte).

The direction is also unclear: getsockopt(2) and setsockopt(2) explicitly
indicate whether the data is being written to the socket or read from the
socket, whereas there's no such explicit indication for the msg_control path.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 271607] 14.0-RELEASE metabug

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271607
Bug 271607 depends on bug 273661, which changed state.

Bug 273661 Summary: freebsd-update install: ///usr/include/c++/v1/__string 
exists but is not a directory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 274226] No documentation for sendmsg/recvmsg ancilliary data.

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274226

Graham Perrin  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
   Keywords||needs-qa
 Status|New |Open

--- Comment #1 from Graham Perrin  ---
Thanks, and for convenience, online views of the first two pages: 







-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 273809] Thinkpad T430 headphones don't work

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273809

--- Comment #11 from Oleksandr Kryvulia  ---
Please post the output mentioned in comment #1

-- 
You are receiving this mail because:
You are the assignee for the bug.