I think the justification for the original comment is: epoll_wait returns either when events are available, or the timeout is hit -> and if the timeout is hit, "event is available" is undefined (or another way: it would be incorrect to interpret a timeout being hit as "no events available"). So one could justify this missed event that way, but it does feel against the spirit of the API, especially since the event may have existed for an infinite amount of time, and still be missed.
Glancing again at this code, ep_events_available() should return true if rdllist is not empty, is actively being modified, or if ovflist is not EP_UNACTIVE_PTR. One ordering thing that sticks out to me is ep_start_scan first splices out rdllist, *then* clears ovflist (from EP_UNACTIVE_PTR -> NULL). This creates a short condition where rdllist is empty, not being modified, but ovflist is still EP_UNACTIVE_PTR -> which we interpret as "no events available" - even though a local txlist may have some events. It seems like, for this lockless check to remain accurate, we should need to reverse the order of these two operations, *and* ensure the order remains observable. (and for users using the lock, there should be no observable difference with this change)
