Re: Kqueues and fork

On Mon, Aug 25, 2025 at 10:59:17AM -0400, John Baldwin wrote:
> On 8/21/25 03:45, Konstantin Belousov wrote:
> > Process notes should be easier, there mostly the pids need fixing.
> 
> This note jumped out at me (and EVFILT_PROC is one of the filters I think has
> the potential to not be straightfoward with fork()).  What cases do you
> envision rewriting PIDs?  It's not clear to me that there are obvious cases
> (other than perhaps self-referential) where the child wants the PID to
> change.  I can even imagine cases where an application might not want
> self-referential filters to change (e.g. a forking daemon might in the presence
> of forking kqueues register an EVFILT_PROC on its own pid in the parent as
> part of a "template" kqueue so that all children will get an event if the main
> parent process dies).

What I wrote about process notes was not a contract, I intended to do
the pass over all filter types and see what is appropriate to do on fork
for each. In particular, for processes I considered a possibility to do
something special that might be useful for the child.

So far, I only found the special handling really required for the
timers, which appeared the most complicated case due to the allocation
of the data behind knote. The vnode and the netmap filters appeared to
require a refcount fix.

I did not identified any other cases of filters where something is
required on copy.  So for processes I do nothing except the generic
handling of copying the knotes.