Tests for copyin(9) handling of kernel addresses

[kib]

Summary

I wrote morally equivalent tests when I developed the arm patch r289372. The same issue is present on arm64.

[emaste]

Is it worth checking VM_MAXUSER_ADDRESS + 1, 0?

[kib]

In D3925#81835, @emaste wrote:

Is it worth checking VM_MAXUSER_ADDRESS + 1, 0?

(VM_MAXUSER_ADDRESS, 0) is only considered valid because the short-circuit for length == 0 is taken before the interval validation is performed. So, knowing the implementations, I would say that it should be excessive. Still, since the question was raised, I will add the test as well.

[kib]

Add VM_MAXUSER + 1, 0 test.

[ngie]

tests/sys/kern/kern_copyin.c

60–64 ↗

(On Diff #9506)

Creating a temporary file in /tmp violates ATF/kyua's sandbox, even though you call unlink after the fact. Please use copyin.XXXXXX instead

66–78 ↗

(On Diff #9506)

ATF_CHECK(copyin_checker... == 0); is the same thing. I don't know if jmmv had a preference but IIRC the more complex macros were going to be removed, maybe, someday (yes, I am being wishy-washy on purpose here).

[kib]

Do not create temp file in /tmp. Use ATF_CHECK instead of ATF_CHECK_EQ.

[ngie]

Sidenote: the only thing that's slightly painful with ATF that other test infrastructures seem to do better is that ATF_CHECK/ATF_REQUIRE don't print out the result of the expression, so if you need to dump out the result of the check, use ATF_CHECK_MSG/ATF_REQUIRE_MSG instead, like:

int rc;

ATF_CHECK_MSG((rc = foo()) == exp_result, "foo() failed. Expected: %d; got: %d");

LGTM!

[kib]

In D3925#81898, @ngie wrote:

int rc;

ATF_CHECK_MSG((rc = foo()) == exp_result, "foo() failed. Expected: %d; got: %d");

This is extremely ugly. For my tests, the function is the same, but the arguments are what produce the test case. In essense, I have to either retype the same thing twice, or create a wrapper that would call ATF_CHECK_MSG() only in case of failure.

I decided to keep this as is, since the most likely outcome of the failing test is the kernel panic, anyway.

[ngie]

In D3925#81904, @kib wrote:

In D3925#81898, @ngie wrote:

int rc;

ATF_CHECK_MSG((rc = foo()) == exp_result, "foo() failed. Expected: %d; got: %d");

This is extremely ugly. For my tests, the function is the same, but the arguments are what produce the test case. In essense, I have to either retype the same thing twice, or create a wrapper that would call ATF_CHECK_MSG() only in case of failure.

Yes, I wish it was more user friendly...

I decided to keep this as is, since the most likely outcome of the failing test is the kernel panic, anyway.

0-o...