A change related to this broke CI (example):

...
Fail: incorrect exit status: 1, expected: 0
stdout:

1. This broke the build with i386:

11:40:34 --- all_subdir_aesni ---
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c: In function 'xor_and_encrypt':
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:61:18: error: incompatible types when initializing type '__m128 {aka __vector(4) float}' using type '__m128i {aka __vector(2) long long int}'
11:40:34   __m128 retval = _mm_xor_si128(a, b);
11:40:34                   ^~~~~~~~~~~~~
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:63:21: error: incompatible type for argument 3 of 'aesni_enc'
11:40:34   retval = AESNI_ENC(retval, k, nr);
11:40:34                      ^
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:47:64: note: in definition of macro 'AESNI_ENC'
11:40:34  #define AESNI_ENC(d, k, nr) aesni_enc(nr-1, (const __m128i*)k, d)
11:40:34                                                                 ^
11:40:34 In file included from /workspace/src/sys/crypto/aesni/aesni_ccm.c:46:0:
11:40:34 /workspace/src/sys/crypto/aesni/aesencdec.h:115:1: note: expected '__m128i {aka const __vector(2) long long int}' but argument is of type '__m128 {aka __vector(4) float}'
11:40:34  aesni_enc(int rounds, const __m128i *keysched, const __m128i from)
11:40:34  ^~~~~~~~~
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:64:9: error: incompatible types when returning type '__m128 {aka __vector(4) float}' but '__m128i {aka __vector(2) long long int}' was expected
11:40:34   return (retval);
11:40:34          ^
11:40:34 /workspace/src/sys/crypto/aesni/aesni_ccm.c:65:1: error: control reaches end of non-void function [-Werror=return-type]
11:40:34  }
11:40:34  ^

2. Why didn't someone from secteam sign off on this change (CC: secteam)?

In D20092#434855, @trasz wrote:

In D20092#433990, @ngie wrote:

This looks good to me (not a ports committer though, so just reviewing the change).
As a volunteer/co-maintainer on the LTP project, your suggestions make sense.
The only thing that I would do is install LTP to /compat/linux/opt, if at all possible. If not, we can come up with a better way to build/relocate LTP (I wrote the current build system about a decade ago for the project).

But it does install to /compat/linux/opt - except for the documentation (where it follows Linux conventions) and two binaries - not sure what's going on with those two.

The user space and test changes all look great. I’ll defer to someone else (like kib@) about the VM changes.

In D20005#430003, @cem wrote:

It's not a static number, AFAICT, depending on how the kernel maps libraries or waves hands does stuff with virtual memory. Hence the sloppy 66xxx match. I think @lwhsu's proposal is something like atf_check [ "$num" -gt 65535 ], which verifies that the number exceeds the lower 16 bit limit (which is the coredump feature the regression test is attempting to verify).

This looks good to me (not a ports committer though, so just reviewing the change).

In D20124#433272, @ngie wrote:

I’m a bit ambivalent about this change, because it’s up on the wiki in greater detail: https://wiki.freebsd.org/TestingFreeBSD . kyua(1) references atf(7) IIRC, but it’s a level of indirection.
My point is, I’d personally prefer not mentioning just ATF in tests(7), but I want it to be enough of a living document where multiple sources can contribute to it, but mentioning the wiki page doesn’t seem like something that’s generally done from a manpage because the location and content in a wiki page can change.

I’m a bit ambivalent about this change, because it’s up on the wiki in greater detail: https://wiki.freebsd.org/TestingFreeBSD . kyua(1) references atf(7) IIRC, but it’s a level of indirection.

I'm ok with the changes, but there are some kinks that should probably be worked out before committing this.

I don't think benchmarks is an appropriate category. LTP consists primarily of functional and crash tests.

This change is very reasonable.