linux-kernel - Re: [PATCH 2/2] eventpoll: Fix epoll

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250718085948.3xXGcxeQ@linutronix.de>
Date: Fri, 18 Jul 2025 10:59:48 +0200
From: Nam Cao <namcao@...utronix.de>
To: Soheil Hassas Yeganeh <soheil@...gle.com>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Shuah Khan <shuah@...nel.org>, Davidlohr Bueso <dave@...olabs.net>,
	Khazhismel Kumykov <khazhy@...gle.com>,
	Willem de Bruijn <willemb@...gle.com>,
	Eric Dumazet <edumazet@...gle.com>, Jens Axboe <axboe@...nel.dk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH 2/2] eventpoll: Fix epoll_wait() report false negative

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@...utronix.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