On Wed, 29 Apr 2026 08:54:06 +0200 Christian Brauner <[email protected]> wrote:
> On Fri, Jul 18, 2025 at 10:59:48AM +0200, Nam Cao wrote: > > 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 <[email protected]> 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. > > The selftests rely on this behavior that timeout=0 sees events from a > concurrently running producer. They would fail at a very higher rate > after this change - believe me I had a similar patch that changed > something in this area. I would explore the seqcount that Mateusz > suggested tbh. > Does this scenario really affect any real programs? It doesn't make sense to have multiple threads looking for level-triggered events on a single epoll fd. When epoll returns an event you really need to do a (usually) read on the associated file descriptor before calling epoll again. To split the epoll processing between multiple threads you need lots of epoll fd with the underlying fd distributed between them and get the threads to process the epoll fd sequentially (eg by putting the fd in an array and using an atomic increment of a global array index to get the next epoll fd to process). -- David
