tests/unix_passfd: test that control mixed with data creates records

[glebius]

Summary

If socket has data interleaved with control it would never allow to read
two pieces of data, neither two pieces of control with one recvmsg(2). In
other words, presence of control makes a SOCK_STREAM socket behave like
SOCK_SEQPACKET, where control marks the records. This is not a documented
or specified behavior, but this is how it worked always for BSD sockets.
If you look closer at it, this actually makes a lot of sense, as if it
were the opposite both the kernel code and an application code would
become way more complex.

The change made recvfd_payload() to return received length and requires
caller to do ATF_REQUIRE() itself. This required a small change to
existing test rights_creds_payload. It also refactors a bit f28532a0f363,
pushing two identical calls out of TEST_PROTO ifdef.

[markj]

tests/sys/kern/unix_passfd_test.c

207

Since this function does not return negative values (it asserts that recvmsg() does not fail), it can return a size_t, so callers don't need to cast.

968

This line does nothing, the loop will iterate once.

971

Same here.

[glebius]

oops, should be <=. I've been testing it wrong all the time.

[glebius]

Fix cycles to actually do the test!

[glebius]

tests/sys/kern/unix_passfd_test.c

207

I'd prefer not to. Now there is one caller that casts and one that doesn't cast, as it compares to another ssize_t. Potentially in the future internal assertion can be removed if yet another test would want to check that recvfd_payload() actually failed. Like we already have for sendfd_payload().

[markj]

tests/sys/kern/unix_passfd_test.c

952

970

IMO it is worth asserting that close() returns 0. It can help catch test bugs at least.

[glebius]

Assert close(2) was successful.

[glebius]

Fix grammar.

[markj]

tests/sys/kern/unix_passfd_test.c

970

Missed this naked close() call. Yes it is probably excessive, but it doesn't hurt.