tests: kqueue: add a basic test for CPONFORK

[kevans]

Summary

Just copy over a timer and a write-filter, be sure that we can observe
both in the child. Maybe the timer should check for a minimum time
passed, but I don't know that we'd be likely to get that wrong.

[kib]

tests/sys/kqueue/kqueue_fork.c

112

I would went as far as adding a check that kq is a valid file descriptor in the child. E.g. you could use fcntl(F_KINFO) and check its succeeded and the fd type.

Before the fork support, kqueue fds were automatically closed in children.

117

133

And check the mask in the parent.

[kevans]

Address review feedback: sanity check the kq fd and push mask checking to parent

Additionally:

• Switch to EVFILT_VNODE instead of EVFILT_WRITE, because the former is what I really wanted; an event that will always fire is less useful.
• Actually check kevent() return in the child to be sure that we didn't hit call timeout

[kib]

tests/sys/kqueue/kqueue_fork.c

123

133

I think err would not quite work in the child. Why not _exit(RECV_ERROR)?

[kevans]

Review feedback: push .kf_structsize into initializer, err(3) -> _exit(2)

[kib]

tests/sys/kqueue/kqueue_fork.c

108

No error checking?

137

I think there is a small flaw. Since ts is not updated by kevent(2), any wakeup causes re-arm of the timeout. To be completely proof, you would check the absolute time after recording the received events.

But this is probably overkill.

[kevans]

Address review feedback, add missing error check

Arm a one-shot timer after the fork for the timeout, instead of using the
kevent() timeout mechanism. The potential delays were considered acceptable,
but we can easily arm a second timer after the fork to provide an absolute
timeout of 4 seconds.

[markj]

tests/sys/kqueue/kqueue_fork.c

168

Why close the kqueue here?

[kevans]

tests/sys/kqueue/kqueue_fork.c

168

I was thinking along the lines of demonstrating that the forked kqueue is completely independent from the parent copy / ensuring that notes are actually copied. It occurs to me that it could be useful to do this but also confirm that we actually see all of the expected events on both queues.

[markj]

tests/sys/kqueue/kqueue_fork.c

168

That'd be a good extension, yeah. Making sure that forking doesn't somehow "steal" the knotes.

[kevans]

One last round of improvements:

• Instead of closing kqueue in the parent, confirm that we get all of the events still
• Also add in an EVFILT_READ with a close-on-fork fd (well, a kqueue) to show that it only goes away in the child

[kevans]

Hmm, The second kqueue might not be as useful as I've thought. It doesn't mean much because the filter needs to resolve the fd first, which will EBADF early.

[kib]

In D56223#1286935, @kevans wrote:

Hmm, The second kqueue might not be as useful as I've thought. It doesn't mean much because the filter needs to resolve the fd first, which will EBADF early.

Then why playing with EV_DISABLE/EV_ENABLE at all? Add the normal event to the kqueue. After that, if knote is activated, you should get the event in the parent but not in the child. Basically, remove the EV_DISABLE flag, and the call to kqueue to activate in the child.

[kevans]

Fix the close-on-fork fd test: add an EVFILT_USER to the second kqueue and
trigger it, then confirm that the parent sees the read-event while the child
does not. This shouldn't be fragile because the EVFILT_READ will be readable
as of the very first scan in the child, so things would have to go pretty wrong
for it to appear but not beat the 3-second timer to being observed.

[kib]

tests/sys/kqueue/kqueue_fork.c

167

This comment is no longer true for clofd, I believe.