All of lore.kernel.org
 help / color / mirror / Atom feed
From: YiFei Zhu <zhuyifei1999@gmail.com>
To: Anton Ivanov <anton.ivanov@kot-begemot.co.uk>
Cc: linux-um@lists.infradead.org
Subject: Re: Race between SIGIO and epoll from SMP host
Date: Thu, 22 Apr 2021 03:46:43 -0500	[thread overview]
Message-ID: <CABqSeATCv1d+OgaWZwuM4kdLYq-iSei+te3E-wp=SvyTaTYsBg@mail.gmail.com> (raw)
In-Reply-To: <bb88a493-7db5-d508-8a07-bcd80e550347@kot-begemot.co.uk>

On Thu, Apr 22, 2021 at 2:32 AM Anton Ivanov
<anton.ivanov@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

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


  parent reply	other threads:[~2021-04-22  8:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 11:53 Race between SIGIO and epoll from SMP host YiFei Zhu
2021-04-21 12:32 ` Anton Ivanov
2021-04-21 12:45   ` Anton Ivanov
2021-04-21 13:35   ` YiFei Zhu
2021-04-21 14:21     ` Anton Ivanov
2021-04-21 15:45     ` Anton Ivanov
2021-04-22  7:32       ` Anton Ivanov
2021-04-22  7:50         ` Anton Ivanov
2021-04-22  8:46         ` YiFei Zhu [this message]
2021-04-22 11:27           ` Anton Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABqSeATCv1d+OgaWZwuM4kdLYq-iSei+te3E-wp=SvyTaTYsBg@mail.gmail.com' \
    --to=zhuyifei1999@gmail.com \
    --cc=anton.ivanov@kot-begemot.co.uk \
    --cc=linux-um@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.