On Fri, Jul 18, 2025 at 09:38:27AM +0100, Soheil Hassas Yeganeh wrote: > On Fri, Jul 18, 2025 at 8:52 AM Nam Cao <namcao@xxxxxxxxxxxxx> wrote: > > > > ep_events_available() checks for available events by looking at ep->rdllist > > and ep->ovflist. However, this is done without a lock, therefore the > > returned value is not reliable. Because it is possible that both checks on > > ep->rdllist and ep->ovflist are false while ep_start_scan() or > > ep_done_scan() is being executed on other CPUs, despite events are > > available. > > > > This bug can be observed by: > > > > 1. Create an eventpoll with at least one ready level-triggered event > > > > 2. Create multiple threads who do epoll_wait() with zero timeout. The > > threads do not consume the events, therefore all epoll_wait() should > > return at least one event. > > > > If one thread is executing ep_events_available() while another thread is > > executing ep_start_scan() or ep_done_scan(), epoll_wait() may wrongly > > return no event for the former thread. > > That is the whole point of epoll_wait with a zero timeout. We would want to > opportunistically poll without much overhead, which will have more > false positives. > A caller that calls with a zero timeout should retry later, and will > at some point observe the event. Is this a documented behavior that users expect? I do not see this in the man page. It sounds completely broken to me that an event has been sitting there for some time, but epoll_wait() says there is nothing. > I'm not sure if we would want to add much more overheads, for higher precision. Correctness before performance please. And I'm not sure what you mean by "much more overheads". While this patch definitely adds some cycles in case there is no event, epoll_wait() still returns "instantly". Nam
