linux: don't delay EPOLL_CTL_DEL operations

[bnoordhuis]

Perform EPOLL_CTL_DEL immediately instead of going through io_uring's submit queue, otherwise the file descriptor may be closed by the time the kernel starts the operation.

---

I still need to steal adopt Santi's test case but I ran out of time for the day.

[santigimeno]

LGTM

[vtjnash]

SGTM.

However, will this still leave open a race window if a user adds an event for only a short period of time or changes the set of events, if the following sequence occurs, or is that prevented by uv__epoll_ctl_flush:

• user calls uv__epoll_ctl_prep(EPOLL_CTL_ADD)
• user calls uv_close()
• libuv calls epoll_ctl(EPOLL_CTL_DEL) # which fails, since EPOLL_CTL_ADD hasn't completed yet
• kernel processes uv__epoll_ctl_prep(EPOLL_CTL_ADD)
• libuv calls close() # which triggers this kernel issue with fd that are in epoll

If this is prevented by uv__epoll_ctl_flush, then would an alternative approach that preserves some of this batching to move add a uv__epoll_ctl_flush just before the close-callback phase of the event loop, but only if there are both pending flush and pending close calls? (and assuming it is still careful around a uv_poll_stop call, which is documented to run synchronously with respect to subsequent close calls)

[bnoordhuis]

I don't think that can happen. Before io_uring, we basically called epoll_ctl(EPOLL_CTL_ADD) in a loop at the start of uv__io_poll() right before calling epoll_pwait().

Now, we use io_uring as a kind of vectored epoll_ctl but everything still happens at the start of uv__io_poll().

I could nop out the sqe in uv__platform_invalidate_fd() but that's a) another linear scan and we already have one of those, and b) dead code, I'm fairly sure.

I'll push a commit that shows what I mean but I observe that our test suite never hits that code path.

[bnoordhuis]

Also, given the above and given that after this commit EPOLL_CTL_DEL no longer goes through io_uring, there's probably room to simplify src/unix/linux.c.

[oscardssmith]

is this ready to merge?

[bnoordhuis]

Incorporated Santi's test case and simplified the logic in linux.c, PTAL.

[santigimeno]

It seems the new test is failing to build on macos though