From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5DDFC432C3 for ; Thu, 14 Nov 2019 09:20:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 827DF206C0 for ; Thu, 14 Nov 2019 09:20:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=rasmusvillemoes.dk header.i=@rasmusvillemoes.dk header.b="HUIEkJPB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726057AbfKNJUE (ORCPT ); Thu, 14 Nov 2019 04:20:04 -0500 Received: from mail-lf1-f66.google.com ([209.85.167.66]:43587 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbfKNJUC (ORCPT ); Thu, 14 Nov 2019 04:20:02 -0500 Received: by mail-lf1-f66.google.com with SMTP id q5so4428749lfo.10 for ; Thu, 14 Nov 2019 01:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VWOUZ424cqLg2kuzZsAep0k1VB5L7ThfcMMEDK+H8tc=; b=HUIEkJPB/6glFajby5ySDEps1DnotXVu1qEtQ0BwJWhu32tz/9zrUk7HdFdvFdnNHH dxO3Rk/YldlDxbgdprqwpmmDNlU0fPIxF97ZmXNrwyUWh/QgNIbKxhMUIrEaKZy8LBu6 f1wjBruA5fQCQetB0h1yhtxHaFdrfrDDMCpmg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VWOUZ424cqLg2kuzZsAep0k1VB5L7ThfcMMEDK+H8tc=; b=NUSxLlkkOPrtMMKuuancATauaosNAXDbEMrZtx9W3Y6Y+MyG+A6tN4O/5Br1FjAsLu FR9UNncWX7KH4g6m1A7BGFAuKe6MRwCBaQR+JCb52dsj6Pg0JHSCVjDGLghxgom7+Vd1 DXDBIlgMfcjkvpX5IfGqOC7/ABQF9wK9J+pvh/yajfHOSK/TkjPwzOpJ0nsSasOJHdqC rYUHkeNOA8rKxUulJF0OjxahsKBjiqwJ3SxMzIuMH7/gSpeXUL5Yda+OxVIpBT1s/1O9 1aP0y6mJriruqOfPj4fA36tQcHdOl2FvxBhTi3w8nUKsMKn9OHQeT/mpgfdCz73Twosk I8lw== X-Gm-Message-State: APjAAAWUr/Zq6EcGb7RigKJU1RMZztgG9eHW5mXxYri5P/33ow3Ap5bk 1e0r+c8Xa3R2O5KyDGGzCMFEUA== X-Google-Smtp-Source: APXvYqxa+8hUQhuGo9CVK60WwB6YzT9RYvrAB8YbUsHzRM4krnVwhJA1CpZIqJ4DKRffScVNO6jzXQ== X-Received: by 2002:ac2:5c4e:: with SMTP id s14mr6047944lfp.23.1573723199828; Thu, 14 Nov 2019 01:19:59 -0800 (PST) Received: from [172.16.11.28] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id 190sm2535102ljj.72.2019.11.14.01.19.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Nov 2019 01:19:59 -0800 (PST) Subject: Re: [PATCH RFC] io_uring: make signalfd work with io_uring (and aio) POLL To: Jens Axboe , io-uring@vger.kernel.org, "linux-kernel@vger.kernel.org" Cc: Alexander Viro , Andrew Morton , linux-fsdevel , Christoph Hellwig References: <58059c9c-adf9-1683-99f5-7e45280aea87@kernel.dk> <58246851-fa45-a72d-2c42-7e56461ec04e@kernel.dk> From: Rasmus Villemoes Message-ID: Date: Thu, 14 Nov 2019 10:19:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <58246851-fa45-a72d-2c42-7e56461ec04e@kernel.dk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On 14/11/2019 05.49, Jens Axboe wrote: > On 11/13/19 9:31 PM, Jens Axboe wrote: >> This is a case of "I don't really know what I'm doing, but this works >> for me". Caveat emptor, but I'd love some input on this. >> >> I got a bug report that using the poll command with signalfd doesn't >> work for io_uring. The reporter also noted that it doesn't work with the >> aio poll implementation either. So I took a look at it. >> >> What happens is that the original task issues the poll request, we call >> ->poll() (which ends up with signalfd for this fd), and find that >> nothing is pending. Then we wait, and the poll is passed to async >> context. When the requested signal comes in, that worker is woken up, >> and proceeds to call ->poll() again, and signalfd unsurprisingly finds >> no signals pending, since it's the async worker calling it. >> >> That's obviously no good. The below allows you to pass in the task in >> the poll_table, and it does the right thing for me, signal is delivered >> and the correct mask is checked in signalfd_poll(). >> >> Similar patch for aio would be trivial, of course. > > From the probably-less-nasty category, Jann Horn helpfully pointed out > that it'd be easier if signalfd just looked at the task that originally > created the fd instead. That looks like the below, and works equally > well for the test case at hand. Eh, how should that work? If I create a signalfd() and fork(), the child's signalfd should only be concerned with signals sent to the child. Not to mention what happens after the parent dies and the child polls its fd. Or am I completely confused? Rasmus