So, why mess with the types (int -> bool and int -> u_long)? Strictly speaking it is not necessary and I can revert it if you prefer. I note though that there is no TUNABLE_UINT() and a comment for TUNABLE_INT() suggests not to use it. I don't know why this is, but just converting to bool and u_long seems fine anyway.

Addressing problems uncovered in testing. I had assumed that the
mechanism used by debug.witness.witness_count actually worked, but it
didn't. I added a new patch D57613 to address the problem with
witness_count by itself, and then applied that fix here too. I also
fixed an alignment problem.

Looks good. I presume you've tested it?

Abandoning this for now, though I still think it would be fine to take. I addressed some of the underlying issues with D56894 and D56946.

Also make the vnlru_read_freevnodes() call conditional.

Regarding braces... I prefer to leave it with the braces. My preference is to apply to both branches if applied to one. Style says "may" be left out. There are many examples of the balanced use, including about 10 in this file.

In D56951#1304662, @olce wrote:

Seems reasonable. Do you have any specific benchmark showing an actual improvement?

kib feedback: try working from the bottom up instead. This has the asm
files declare that they don't need an executable stack. It does still
leave this issue building linux.ko.full:
ld: warning: linux32_vdso.so: missing .note.GNU-stack section implies executable stack

In D56894#1303307, @rlibby wrote:

Okay I started on adding .section .note.GNU-stack,"",%progbits to the asm files, https://github.com/rlibby/freebsd/commit/8e408b3197545f47bd2db1c4827507c503d1d049

But I still see one of the warnings, so I must be missing something...

./sys/GENERIC/modules/usr/src/freebsd/sys/modules/linux/linux.ko.full.meta:/usr/local/x86_64-unknown-freebsd16.0/bin/ld: warning: linux32_vdso.so: missing .note.GNU-stack section implies executable stack

Okay I started on adding .section .note.GNU-stack,"",%progbits to the asm files, https://github.com/rlibby/freebsd/commit/8e408b3197545f47bd2db1c4827507c503d1d049

In D56894#1303299, @kib wrote:

In D56894#1303296, @rlibby wrote:

In D56894#1303295, @kib wrote:

IMO both vdso must be build with nonexec stack, and it is better to explicitly add the gnu section to sources marking the objects.

Ack, I'll see if I can figure that out. I think this will add the section to the .so objects, but I'll see if I can get it applied earlier.

Not a section, but the non-loadable segment PT_GNUSTACK. Either way it appears in the resulting dso, but when specified using section in the source, it it explicit.
I believe linker reports which files are missing it, no?

	.section .note.GNU-stack,"",%progbits

In D56894#1303295, @kib wrote:

IMO both vdso must be build with nonexec stack, and it is better to explicitly add the gnu section to sources marking the objects.

Okay, sounds good. I'll skip the exp-run on this and plan to push it probably on Friday afternoon.

In D56783#1300973, @emaste wrote:

Seems fine to me. Is it worth an exp-run?

imp & jrtc27 feedback: don't repeat the long size detection logic

rmacklem feedback: nfs_pub can be static in vfs_export.c

Move providing type size macros to a parent commit.

I don't feel strongly about it, beyond wanting the gcc build to work. If @kib and @imp you guys don't agree on the direction here, my inclination is just to leave it as it is after 00dccc3164c6dff38350a1baeeea7238acf2efc3 and move on.

What do you think of this? https://github.com/rlibby/freebsd/commit/73605b3a9268d5ea7ad52650ba9ba7c808842dc5