From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]) by bombadil.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lZUz9-00DW29-7e for linux-um@lists.infradead.org; Thu, 22 Apr 2021 08:46:56 +0000 Received: by mail-pl1-x630.google.com with SMTP id h20so23179202plr.4 for ; Thu, 22 Apr 2021 01:46:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: YiFei Zhu Date: Thu, 22 Apr 2021 03:46:43 -0500 Message-ID: Subject: Re: Race between SIGIO and epoll from SMP host List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: Anton Ivanov Cc: linux-um@lists.infradead.org On Thu, Apr 22, 2021 at 2:32 AM Anton Ivanov 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