tests/unix_passfd: sending many and too many SCM_RIGHTS

[glebius]

Summary

o Exercise bounds checking when sending large set of file descriptors,

that can't fit into single control mbuf.

o Exercise resource limits checks when receiving a large sets.
o Check that socket isn't left in a completely stuck state when we can't

receive SCM_RIGHTS due to limits.  Current SOCK_STREAM socket would
free the control, but leave the data in.  This seems to be a legit
behavior for a stream socket, as we don't want holes in the data.

[markj]

tests/sys/kern/unix_passfd_test.c

381

BTW, I wondered in the past about whether this limit should be formally defined somehow. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239250

394

Probably you should initialize ch to avoid static analysis warnings.

418

Do you need to set rlim_max too?

[glebius]

tests/sys/kern/unix_passfd_test.c

381

I didn't find any formal definition. Should I mention PR in the commit?

394

Will do.

By the way, if msghdr doesn't have any iovecs, we hit really ugly bugs in SOCK_STREAM. The first too big send (line 405) would fail as expected. The second send (L411) will succeed. The receive would succeed (L413) and nfds would grow (L414). Then next one sendmsg would succeed, but the recvmsg that is expected to fail (L425) would succeed . It would not bring any new descriptors though, nfds would stay at the old value. Dtracing shows that both unp_internalize() is executed within sendmsg() and unp_externalize() is executed with recvmsg(), both return 0.
Having this byte of non-control data eliminates the problem. This might explain why other tests in this file do the same.

Given what a mess is soreceive_generic() I decided to leave the problem for later.

418

No, we don't need that. It also would fail from non-root user.

[markj]

tests/sys/kern/unix_passfd_test.c

381

I do not know if any other OS defines it somehow. Maybe the real solution is to permit SCM_RIGHTS messages to span multiple clusters.

I don't think it'd be very useful to reference the PR, but feel free.