In D56312#1290228, @markj wrote:

In D56312#1289914, @aokblast wrote:

In D56312#1289170, @markj wrote:

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

The MSR involved isn’t publicly documented; it’s only used to disable RDSEED across the Linux kernel (see the reference here: https://elixir.bootlin.com/linux/v6.19.11/source/arch/x86/kernel/cpu/amd.c#L1043
).
The logic is straightforward: it reads the MSR, checks whether the relevant bit is enabled, and clears it if so. If the bit isn’t set, it does nothing.
I haven’t been able to test this yet since it requires a Linux 6.19+ kernel. I’m still waiting for feedback from the reporter.

Then, don't we want to honour the MSR by ensuring that CPUID_STDEXT_RDSEED is not returned in x86_emulate_cpuid()?

In D56330#1290467, @dan.kotowski_a9development.com wrote:

Put #ifndef _LOCORE around the proto.

With _LOCORE I had the same build error. I was able to proceed by using LOCORE instead.

diff --git a/sys/x86/include/cputypes.h b/sys/x86/include/cputypes.h
index ed26304a89ac..0b6f0f3746a9 100644
--- a/sys/x86/include/cputypes.h
+++ b/sys/x86/include/cputypes.h
@@ -54,7 +54,9 @@
 #define CPU_AMD_UNKNOWN                0xffffffff
 
 #ifdef _KERNEL
+#ifndef LOCORE
 u_int  ident_zen_cpu(void);
 #endif
+#endif
 
 #endif /* !_X86_CPUTYPES_H_ */

--------------------------------------------------------------
>>> Kernel build for GENERIC completed on Mon Apr 13 16:27:27 UTC 2026
--------------------------------------------------------------
>>> Kernel(s)  GENERIC built in 144 seconds, ncpu: 32, make -j32
--------------------------------------------------------------

Use correct name

As reported by https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=294468, cputypes.h is used in ASM code on i386 build so we cannot put the function declaration inside cputypes.h. machine/cpu.h also has this issue. @kib, is there any place you think that we can put?

In D56312#1289170, @markj wrote:

Are these MSRs documented anywhere? Why is it always correct to return 0 when reading?

Move the check beforehead

Move function prototype

Loop the whole array and put the macro to other file

This was also a requirement for https://reviews.freebsd.org/D56332 and should be useless now. However, amdtemp driver now hardcode this zen detection logic in the amdtemp.c file, we can use ident_zen_cpu to refactor the amdtemp code.

In D56331#1288977, @kib wrote:

Can you explain why is it needed?

Use structure instead of ifdef.

LGTM

In D56332#1288903, @markj wrote:

In D56332#1288887, @aokblast wrote:

I came across this in a Bugzilla report. As described in the commit message, it may pollute the system entropy pool. Although the microcode fix is already included in the latest AGESA release from earlier this year—so systems with updated BIOS firmware should be unaffected, not all users regularly update their BIOS, and not all vendors have distributed the patch.

Given that, I think this issue is still worth taking a closer look.

Per https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7055.html (and the linked thread), only rdseed with a 16-bit or 32-bit operand is affected, but here it's a 64-bit output.

I came across this in a Bugzilla report. As described in the commit message, it may pollute the system entropy pool. Although the microcode fix is already included in the latest AGESA release from earlier this year—so systems with updated BIOS firmware should be unaffected, not all users regularly update their BIOS, and not all vendors have distributed the patch.

I feel like the grammar is wrong but since I am not a native English speaker....

Remove unneeded change

In D56022#1282431, @kib wrote:

In D56022#1282270, @aokblast wrote:

In D56022#1281980, @kib wrote:

No. Perhaps it is simpler to show code than to try to explain it, See D56053.

The example you provided would not work with my patch, it requires increasing the CXA_DTORS_ITERATIONS. Not sure if we want this.

If it breaks the valid C++ code, we should rethink about it. The T value can be somehow greater than CXA_DTORS_ITERATIONS if the user wants.

I do not disagree but there are also some robustness requirements as part of the implementation quality. So I am unsire, this is why I initially said that 'I am on edge' proposing this. Hanging in the system state (thread exiting) due to user bug is not robust.

That said, your patch should remove walk_cb_nocall(). And perhaps cxa_thread_walk() could drop the argument, simply inlining walk_cb_call.

Remove more unused code

In D56267#1287651, @bz wrote:

I wonder multiple things:
(a) is this a problem with umask for the wpa_supplicant process and could be fixed in the startup script for the general FreeBSD case for as long as a user does not run things manually?

No, other wpa consumer, like the wutui from GSoC 2025 can trigger this.

(b) should the code not check the original config file permissions and apply these? (generic solution?)

Yes, you are right. Fix it now! Thanks!

(c) if there is no file, hard coding these as for android would need #ifdef around.

Ok.

Apply permission by honoring original permission

Minor fixes

Fix FPS parse

Fixup for sysctl node

In D56053#1284052, @markj wrote:

Seems ok, but I'm not sure if it's sufficient for the LLVM test case that @aokblast was looking at.

Minor fixes

Fixes

Fix also in stdext and stdext3

In D56022#1281980, @kib wrote:

No. Perhaps it is simpler to show code than to try to explain it, See D56053.

The example you provided would not work with my patch, it requires increasing the CXA_DTORS_ITERATIONS. Not sure if we want this.

In D56022#1281611, @kib wrote:

I am on edge of proposing to count the number of the list members, and still do the walk_cb_nocall if the number of members does not go to zero after e.g. CXA_DTORS_ITERATIONS times initial list length for dtor removals.

Do you mean something like

Also remove the define

Rename macro

In D55893#1280330, @markj wrote:

BTW, is it possible to create a test case for commit 9d26b82826d9?

Yes, I think we can have some tests for this. But I think we should do it after re-org the tests. At least for now we can rely on the llvm testcase as I run it biweekly with latest CURRENT.

Style and commit msg fix

Return void

Skip the again test

In D55893#1278882, @kib wrote:

In D55893#1278868, @aokblast wrote:

In D55893#1278865, @kib wrote:

No, I mean to keep this test, adjusted.
Create a global static var that is incremented on each again() call, and do not call __cxa_thread_atexit() if the counter greater than some value.
As an additional check, you might assert that the counter indeed counted to the specified value.

In D55893#1278865, @kib wrote:

No, I mean to keep this test, adjusted.
Create a global static var that is incremented on each again() call, and do not call __cxa_thread_atexit() if the counter greater than some value.
As an additional check, you might assert that the counter indeed counted to the specified value.

What about the nothr case? Since there is only one main thread. The dtos will be called after the ATF_TEST_CASE_BODY, which means we are unable to use assert since the main thread is destroyed.

I think that this is the right concern, and the right answer would be to significantly reorg the test. Since we are testing something that checks C runtime behavior outside the scope of normal execution (inside the main) for ATF, we need to create a helper program.
The test should spawn that program and check the effects of it, instead of trying to do everything inline.

In D55893#1278868, @aokblast wrote:

In D55893#1278865, @kib wrote:

No, I mean to keep this test, adjusted.
Create a global static var that is incremented on each again() call, and do not call __cxa_thread_atexit() if the counter greater than some value.
As an additional check, you might assert that the counter indeed counted to the specified value.

In D55893#1278865, @kib wrote:

No, I mean to keep this test, adjusted.
Create a global static var that is incremented on each again() call, and do not call __cxa_thread_atexit() if the counter greater than some value.
As an additional check, you might assert that the counter indeed counted to the specified value.

What about the nothr case? Since there is only one main thread. The dtos will be called after the ATF_TEST_CASE_BODY, which means we are unable to use assert since the main thread is destroyed.

Formatting

Adjust the testcase insteada of deleting the testcase.

In D55893#1278865, @kib wrote:

No, I mean to keep this test, adjusted.
Create a global static var that is incremented on each again() call, and do not call __cxa_thread_atexit() if the counter greater than some value.
As an additional check, you might assert that the counter indeed counted to the specified value.

Reference user: https://github.com/llvm/llvm-project/pull/186961
Raw __elf_aux_vec usage: https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L72

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.

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/.

Minor fixes

I think we need to refactor these stuff to dynamic array in the future. It makes no sense to use linked_list if we only need to push and pop from the top.

Style fix