linux read/write - Write events can be missed if there's insufficient output slots

[arr2036]

Because read/write filters now use a separate struct to track FDs inserted into epoll, and we get aggregate read/write notifications from epoll, if there's only one ev output slot, and the FD is readable and writable, we'd lose the write event.

We need to add knotes into a doubly linked list, and return those before calling the kqops.wait function for a given platform. This should be done in common code with the knote API being extended.

[arr2036]

Confirming this is still a real issue against current master (02709f1).

linux_kevent_copyout (src/linux/platform.c:1107) walks the epoll-returned events in TLS epoll_events[]. For the EPOLL_UDATA_FD_STATE case (line 1171) the dispatcher fires the read knote (1186-1192) and then the write knote (1197-1203), each via linux_kevent_copyout_ev with the remaining caller slot count.

If the caller passed nevents=1 and the fd was both readable and writable, line 1198 hits goto oos between the two and falls through to done: at 1228, returning the count consumed so far. The write event is silently dropped. Worse: any further entries in epoll_events[i+1..nready] are also lost - nothing carries them across the syscall boundary to the next kevent() call.

Sketch of the fix matches the original write-up: a per-kq list (e.g. STAILQ on struct kqueue) of pending (struct epoll_udata *, struct epoll_event) payloads, drained before each fresh kqops.kevent_wait, with insertion / drain under kq_mtx (same lock discipline as fresh dispatch). Lifetime is the interesting part - spill entries need to pin their udata against the deferred-free sweep; bumping the same epoch counter ud_stale already uses should cover it. API needs to be common-code so any backend that aggregates multiple knotes per kernel event can use it. Tests should cover "fd readable+writable with nevents=1" and "epoll_events populated with nready > nevents".

Parked, not fixing in this round.