Potential races in SIGIO vs Epoll order

[YiFei Zhu]

On Tue, May 4, 2021 at 5:42 AM Anton Ivanov
<anton.ivanov at cambridgegreys.com> wrote:
>
> Hi all,
>
> I got around to look at the race discovered by YiFei Zhu in http://lists.infradead.org/pipermail/linux-um/2021-April/001396.html
>
> While UML works using an epoll helper to generate SIGIO, it is ~ 5 times slower compared to enabling async IO. So this is not usable as the primary mode of operation for the interrupt controller.
>
> I am going to play with it a bit further and try get it to do a "epoll not serviced" check only occasionally - to handle errors and IRQ controller stalls.
>
> Brgds,

This might be a dumb idea (tell me if it is), but what if we still
have a helper that runs a defferent epoll fd on the exact same set of
fds as the main thread, and send an additional SIGIO to the main
thread if it notices an epoll event? This way, a SIGIO is guaranteed
to be generated after the wake queue is woken up for epoll events.
What I don't know is if the two different epoll fds will still race in
the wake queue, if the helper's epoll returns first and sends SIGIO to
the main thread before the main thread's epoll receives the event...
Hmm. This would also mean more spurious SIGIOs.

YiFei Zhu