In D58294#1337460, @pouria wrote:

1. Did you use the last version of this patch?

unintentional creation instead of updating D56535

In D58294#1337455, @ivy wrote:

i've done some basic testing with this. IPv4 seems to work with both route(8) and BIRD. IPv6 works with route(8) but not with BIRD:

protocol static {
        ipv6;

        route 2001:db8::/32 via 2a00:1098:6b:401::11 {
                krt_prefsrc = 2001:db8::10;
        };
}

Idx   Type         IFA                           Gateway                        Flags      Use Mtu               Netif           Addrif Refcnt Prepend
10           v6/gw fe80::5a9c:fcff:fe09:c9fd%vtnet0 2a00:1098:6b:401::11       G             0   1500           vtnet0                     2

setting krt_prefsrc in the kernel protocol doesn't make a difference. 2001:db8::10/128 is assigned to lo0 on the test system.

@bnovkov Should I wait for you to test, or are we good to land this?

I have been testing since yesterday. Now, together with D58305. There is nice progress. Thanks a lot for giving the userbase the opportunity to test this upcoming solution.

Hi Emil, I've been pondering this a bit in the last few weeks, trying to learn a bit as I'm going along, and as is probably fairly obvious, with the help of a LLM. I feel like I've made a bit of progress:

i've done some basic testing with this. IPv4 seems to work with both route(8) and BIRD. IPv6 works with route(8) but not with BIRD:

Great catch! Thank you, Jimmy!

In D58316#1337420, @markj wrote:

In D58316#1337411, @rlibby wrote:

Maybe one day we should plumb it for malloc_dbg / memguard_alloc too.

Do you use memguard at all? I haven't needed to reach for it since KASAN was added.

In D58316#1337411, @rlibby wrote:

Maybe one day we should plumb it for malloc_dbg / memguard_alloc too.

Restore P2_ZOMBIEREF_PARENT when reparenting to reaper, to allow reaper do it deeds.

Maybe one day we should plumb it for malloc_dbg / memguard_alloc too.

Tests are passed.
Refactor by breaking prefsrc netlink logic into nl_set_nexthop_prefsrc() and setting the forgotten nh_aifp.
Now, I will wait for D58305, unless the consensus is to NOT limit the ability to set a prefsrc from another fib for VRF route leak.

In D58306#1337381, @bnovkov wrote:

In D58306#1337245, @bz wrote:

Please see the wireless mailing list where I sent a patch for test and did not get feedback. Changing the driver is the wrong thing to do (not that it works well currently).

https://lists.freebsd.org/archives/freebsd-wireless/2026-July/004328.html

Ah, I wasn't aware of your patch, thanks for pointing this out.
FWIW your patch fixes the message spam on my machine.
I'll abandon this revision so please feel free to commit the patch you proposed.

In D58264#1337064, @kib wrote:

In D58264#1337050, @markj wrote:

In D58264#1336261, @kib wrote:

Note that the patch breaks existing tests, but IMO the current behavior is not logical. For instance, when I truss -f /bin/sh using process descriptors, shell is missing the zombie exit status. In other words, pdopenpid() breaks correct code.

Maybe pdwait() shouldn't let you reap a zombie that isn't your child?

This is what the patch does, in fact. We still need to return the data from pdwait(2) if called, so we need to keep the process structure around until both parent and procdesc called their wait(). The patch postpones reap_proc().

In D58306#1337245, @bz wrote:

Please see the wireless mailing list where I sent a patch for test and did not get feedback. Changing the driver is the wrong thing to do (not that it works well currently).

https://lists.freebsd.org/archives/freebsd-wireless/2026-July/004328.html