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 <nam...@linutronix.de> 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
