Shouldn't the third arg be true in this call? In Linux epoll fds are copied across the forks.

Might be. For now I intend to keep existing behavior.

Maybe, "The kqueue descriptor will be inherited by the child, i.e., the numeric value of the descriptor will remain the same."?

Strange indentation here, is it from debugging?

This looks like some debugging.

Indeed this is debugging, I forgot to drop the patch when generating the diff.

Maybe mention that this is contrary to how all other descriptors are treated upon fork(), i.e., we make shallow copies instead.

This comment should be removed or enhanced to explain what is actually happening.

If you handle the !fork_pass case here instead, you can reduce indentation below.

Maybe make a local variable for ofde->fde_file->f_ops so that the lines aren't so long.

Why do we handle DFLAG_FORK in a separate pass? Why not call fo_fork in the first loop?

Inheriting the cpuid like this doesn't really make sense. Ideally the callout will fire on the same CPU where it was scheduled from. Maybe filt_timerstart() should also reset kc->cpuid = PCPU_GET(cpuid).

It is not too unusual for a queue to have several thousand knotes. I suspect this will be slow indeed.

Each FILEDESC_FOREACH_FDE() needs its own block scope unfortunately.

This is the commit message for DFLAG_FORK change:

struct file: add DFLAG_FORK, indicate copying on fork

instead of referencing or ignoring.

The pass to handle copying is performed after all passable files are
installed into the new file descriptor's table, since one of the future
consumers of this interface (kqueue) needs all passable file descriptors
already valid. For the same reason the copying is done in two passes
by itself, first allowing copyable files to be copied, and then giving
the subsystems a second chance to really fill the copied file backing
structure with the content.

[MFC note: use fo_spares for fo_fork]

(and note that kqueue might need the fd number to reference other kqueue)

It is worse at more significant place, knlist_remove_kq().

You might mention somewhere that knotes corresponding to O_CLOFORK fds will not be inherited.

knlist_remove_kq() is just removing a single knote though.

But all knotes are removed eventually, so the same amount of work is spread over the time.

Basically you argue for the same thing that I wanted to do, change this to list. But lets do it separately as a follow-up.