LGTM, please see some comments inline :-)
Also: do you have any preference/requirements on the commit message?

kldload dxr
sysctl net.route.algo should list dxr
sysctl net.route.algo.inet.algo=dxr should forcibly select it

In D28434#672787, @melifaro wrote:

In D28434#672782, @arichardson wrote:

This may be the cause of CI failures starting in build 18011: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/
The only changes are the following the commits (https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/changes):
bddae5c8a64dc6b292198945cbe676bb2158d438, 5d1403a79a3e56403fb63c062252a23fce81e5f1, and 6993187a8c30e83a408aad631a8d8629d8273c9d

Ack. Interesting, local test run worked. Will take a look in the evening.

Should be better with 439d087d0b55.

In D28434#672895, @markj wrote:

In D28434#672871, @markj wrote:

In D28434#672782, @arichardson wrote:

This may be the cause of CI failures starting in build 18011: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/
The only changes are the following the commits (https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/changes):
bddae5c8a64dc6b292198945cbe676bb2158d438, 5d1403a79a3e56403fb63c062252a23fce81e5f1, and 6993187a8c30e83a408aad631a8d8629d8273c9d

It's yet another problem related to type definitions and CTF, causing dtrace to bail. In this case, struct rib_head has a conditionally defined member, rnh_gen_rib. FIB_ALGO is defined only when opt_route.h is included, so unless everything that includes route.h also includes opt_route.h, we end up with different definitions for struct rib_head depending on whether opt_route.h is included. I can see two solutions: move FIB_ALGO to opt_global.h so that FIB_ALGO is consistently defined, or make the definition of rnh_gen_fib unconditional. I prefer the second solution since out-of-tree modules could be compiled without FIB_ALGO defined.

Option 2 landed as bc5ef45aec3fa8acf2dd3408cebd207317543a8b. Thank you!

I misread a bit, the problematic definition is in route_var.h, not route.h, and so is not so widely included in the kernel. Indeed, some files in sys/net/route fail to include opt_route.h. It may be sufficient to just fix those, as a third solution.

In D28434#672782, @arichardson wrote:

This may be the cause of CI failures starting in build 18011: https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/
The only changes are the following the commits (https://ci.freebsd.org/job/FreeBSD-main-amd64-test/18011/changes):
bddae5c8a64dc6b292198945cbe676bb2158d438, 5d1403a79a3e56403fb63c062252a23fce81e5f1, and 6993187a8c30e83a408aad631a8d8629d8273c9d

Ack. Interesting, local test run worked. Will take a look in the evening.

.

I have a general question about compatibility.
Recently I landed a similar change (D28668) in the rtsock space. It turned out that (older) applications do a lot of weird things: some send the length less than expected (recall sockaddr_in has a weird sin_zero field), some send zero-length, etc.
I'm pretty sure that some applications will break in some weird ways - just because we didn't have these checks in place before.
What's our position here? Do we want to let the apps break and insisting on fixing the code, or we consider guarding these checks under, for example #ifndef COMPAT_FREEBSD12?

For the record: I have no context here and this may not be the best fix (e.g. it may be better to just fill at least the ifp pointer during RX ring init), so committing as a bandaid to fix the panic on boot.

In D28886#670581, @arichardson wrote:

In D28886#670565, @melifaro wrote:

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

Just to confirm, rtm_add_v4_no_rtf_host_failure is actually supposed to succeed now?

Yes

In D28886#669858, @arichardson wrote:

@melifaro should I split the change to rtm_add_v4_no_rtf_host_failure into a separate review?

Sorry for taking that long! No, that's totally fine!

Going to commit this on Saturday, April 24

Reflect donner@ comments.

.