Race between SIGIO and epoll from SMP host

YiFei Zhu zhuyifei1999 at gmail.com
Thu Apr 22 09:46:43 BST 2021


On Thu, Apr 22, 2021 at 2:32 AM Anton Ivanov
<anton.ivanov at kot-begemot.co.uk> wrote:
> I now have an idea why we see this on ttys.
>
> TTY IO wake-up in addition to doing SIGIO before poll notifications,
> also does poll notifications using a wake-up which will reschedule.
>
> Compared to that, let's say socket does a sync wake-up which does not
> reschedule and does it before SIGIO.
>
> In either case, we stand a chance of missing an interrupt. Just in the
> second case it is extremely small. So small that I have never seen it in
> practice.
>
> The real way of dealing with it will be to do to do a helper thread
> which (e)polls the epoll fd and generates a SIGIO if there is an
> outstanding EPOLL notification which has been missed. This would also
> take care of the range of conditions which are currently handled by the
> SIGIO fd helper so that would become surplus to requirements.
>
> I think that just polling the epoll fd should do the job here. So this
> will also get rid of all the motions needed to register fds with the
> async helper.
>
> Brgds,

By "async helper" do you mean the sigio helper? Is what you are
suggesting to, in the sigio helper, use epoll instead of using poll,
and then send SIGIO to notify the kernel thread once epoll receives an
event? It sounds like a fix, although no idea how difficult it would
be to efficiently send 'which events have been epolled' back to the
kernel efficiently without running into races.

YiFei Zhu



More information about the linux-um mailing list