In D55833#1278515, @bz wrote:

In D55833#1278447, @jhb wrote:

Ok, so with seq_file fixed, I am now able to build all the debugfs bits in the wireless drivers under CHERI, so I think this finds all of them. I've split out the changes to use simple_read_from_buffer into a separate commit before this one now.

Well, all but rtw88 have debugfs disabled in main and stable/15. I should go and see what it takes to re-enable the other ones as well.

+1 vote for just doing this, all the RIBs built on top of modern FreeBSD FIB need to change with it anyway.

I strongly believe this option is useless now and it just increase complexity of the code.
multipath is part of routing, making it optional is just like making arp/ndp optional in ipv4/ipv6.
the original reason to have this option is no longer valid.
Also, as noted in the d5fe384b4d41a5c5adeaa6039d33d59d7bc33e76, ROUTE_MPATH does not consume memory unless actually used.

In D55833#1278447, @jhb wrote:

Ok, so with seq_file fixed, I am now able to build all the debugfs bits in the wireless drivers under CHERI, so I think this finds all of them. I've split out the changes to use simple_read_from_buffer into a separate commit before this one now.

I'll get back to you within the hour.

Thanks a lot for working on that! I miss the feature a lot.

Correct me if I am wrong, but this seems to be two separate changes. Can this be split please?

Thanks!

Sorry if I wasn't clear - I have no objections against pushing this in. I'm not able to do a protocol level review, but wrt the interaction with the rest of the network stack all looks good to me.

Superseded by D55880.

fix GH_TAGNAME= v${...} to DISTVERSIONPREFIX before @adamw notices 😃

I don't know how to get rid of the warning. I did a testbuild of zls to see if it had the issue too (it does). At that point I decided the issue is somewhere in Uses/zig.mk and I haven't had a chance to investigate.

Use DISTVERSIONPREFIX not GH_TAGNAME=v${...}.
remove DO_MAKE_BUILD_TEST for test-target.

Ok, so with seq_file fixed, I am now able to build all the debugfs bits in the wireless drivers under CHERI, so I think this finds all of them. I've split out the changes to use simple_read_from_buffer into a separate commit before this one now.

Rebase on D55879

Is it possible to fix the warning? If not that's fine.

I think I got the CONFLICTS_INSTALL right (misc/zine also wants to install /usr/local/bin/zine).

In D55860#1278404, @andrew wrote:

Is there a reason to not just read the ID register in the vmm code?

results of poudriere

Is there a reason to not just read the ID register in the vmm code?

results of poudriere

In D55826#1278383, @kib wrote:

In D55826#1278380, @aokblast wrote:

In D55826#1278375, @siva wrote:

@aokblast this commit breaks the following tests in CI:

lib/libc/stdlib/cxa_thread_atexit_nothr_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_add_while_calling_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_after
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_before

See https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/28044/testReport/.

I don't think the test actually make sense with my change.
The following code in the test makes it unables to terminate

static void                                                                                                                                        
again(void *arg)                                                                                                                                   
{                                                                                                                                                  
                                                                                                                                                   
    __cxa_thread_atexit(again, arg, &output);                                                                                                      
}

This makes again(void *) called himself and create a infinite loop. In my opnion, the user of the __cxa_thread_atexit should take the responsibility on the infinite loop instead of setting the hard limit on iteration.

I just take a look at the original commit which add this test and would like to ask @kib and @dim on their opinions.

Should we remove the again function or if there is any suggestions on this?

Indeed this test is perhaps not too useful as is. Might be, it should limit the number of registrations, then it would make some reasonable checks.
I do think that your change that broke the test is right.

In D55826#1278380, @aokblast wrote:

In D55826#1278375, @siva wrote:

@aokblast this commit breaks the following tests in CI:

lib/libc/stdlib/cxa_thread_atexit_nothr_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_add_while_calling_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_after
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_before

See https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/28044/testReport/.

I don't think the test actually make sense with my change.
The following code in the test makes it unables to terminate

static void                                                                                                                                        
again(void *arg)                                                                                                                                   
{                                                                                                                                                  
                                                                                                                                                   
    __cxa_thread_atexit(again, arg, &output);                                                                                                      
}

This makes again(void *) called himself and create a infinite loop. In my opnion, the user of the __cxa_thread_atexit should take the responsibility on the infinite loop instead of setting the hard limit on iteration.

I just take a look at the original commit which add this test and would like to ask @kib and @dim on their opinions.

Should we remove the again function or if there is any suggestions on this?

Also, thanks for your remind:). @siva

In D55826#1278375, @siva wrote:

@aokblast this commit breaks the following tests in CI:

lib/libc/stdlib/cxa_thread_atexit_nothr_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_inf_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_add_while_calling_dtors
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_after
lib/libc/stdlib/cxa_thread_atexit_test:cxx__thread_local_before

See https://ci.freebsd.org/view/Test/job/FreeBSD-main-amd64-test/28044/testReport/.

Thank you pouria!

Hmm, this sounds like another bug. Even if the callout handler is lightweight, I'm sure it plus the overhead of scheduling and running a callout costs more than 1ns. The livelock issue relates to the problem where it becomes impossible to schedule a thread on a looping core, because the softclock thread which runs the callout handler has high priority.

@aokblast this commit breaks the following tests in CI:

Note that this does not change the ABI because although __default_hash has external linkage and went from being a pointer to a function to being an actual function, it was never exported. You may want to mention that in the commit message.