This revision is ready to review.
kind ping :D
@glebius @markj @melifaro

In D58321#1337618, @netchild wrote:

So you disagree with kern.features.exterror.
Do you also disagree with kern.features.exterr_strings which covers the optional behavior of verbose exterror and is useful in unit tests to differentiate between "fails because something is wrong -> error" and "fails because it does not exist -> intendet -> ok".

I can confirm that the configuration below works flawlessly in BIRD:

In D58178#1337559, @kib wrote:

Could somebody provide an isolated test for the situation where the patch is needed?

The start would be to look at the syscall sequence that triggers the problem, with e.g. ktrace.

So you disagree with kern.features.exterror.
Do you also disagree with kern.features.exterr_strings which covers the optional behavior of verbose exterror and is useful in unit tests to differentiate between "fails because something is wrong -> error" and "fails because it does not exist -> intendet -> ok".

Unfortunately, there is very little I can contribute here. My knowledge in regards of all of these FWs is close to zero.

In D58191#1337590, @pho wrote:

I ran all of the stress2 tests without seeing any issues.

I ran all of the stress2 tests without seeing any issues.

• fix typo

HI, my patch is only the library part. It needs extra work to become a driver.

This adds two syscalls to each dynamic syscall failure path. I understand that calling the sysctl is the easiest way to handle dynamically loaded modules. But I already got some negative comments due to exterrors adding some nanoseconds to the failing syscalls timings.
Although I do not object in principle, can we have some smarter way to avoid the sysctl if we already queried the specific module? E.g. we can make each module to register 'range' for dynamic errors' pathes, and memoize the range with the values in libc.
This is esp. sorrow because the display of the source line is really a niche feature.

by the way, there seems to be a typo in the review title :-) (RTA_PERFSRC)

Could somebody provide an isolated test for the situation where the patch is needed?

In D58294#1337514, @ivy wrote:

with D58305 + the new version of D58294, everything seems to be working fine, including with BIRD. (i only did cursory testing, though.)

To whom it may concern: the same problem seems to exist in the Linux source code: cm.c.

• updating phabricator to show proper diff

As I said it elsewhere, there is no point in kern.features.exterror. You cannot run 15 userspace on <= 14 kernel.

The kern.features.exterror part is for the benefit of userland programs which want to use it (e.g. difference between FreeBSD 14.x and 15.x).
The kern.features.exterr_strings part is for the benefit of unit tests to be able to skip if the verbose strings are not enabled.

with D58305 + the new version of D58294, everything seems to be working fine, including with BIRD. (i only did cursory testing, though.)

This should fix it.
Could you please test it again? @ivy @zarychtam_plan-b.pwste.edu.pl

In contrast to ifa_ifwithnet the ifaof_ifpforaddr returns an ifa even if it's not appropriate for prefsrc.
Fix when the interface is specified (which is usually done by ospf) by removing ifaof_ifpforaddr and use ifa_ifwithaddr_fib instead.
Parent: D58305

Updated version at https://reviews.freebsd.org/D58320

REbase in the hope that with this the stack applies cleanly as well.

Just finished reading this, great work! Thank you so much for working on this, @carlavilla !

I'll make the commit this night or tomorrow