public inbox for [email protected]
 help / color / mirror / Atom feed
From: Rasmus Villemoes <[email protected]>
To: Jens Axboe <[email protected]>,
	[email protected],
	"[email protected]" <[email protected]>
Cc: Alexander Viro <[email protected]>,
	Andrew Morton <[email protected]>,
	linux-fsdevel <[email protected]>,
	Christoph Hellwig <[email protected]>
Subject: Re: [PATCH RFC] io_uring: make signalfd work with io_uring (and aio) POLL
Date: Thu, 14 Nov 2019 10:19:58 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

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

  reply	other threads:[~2019-11-14  9:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-14  4:31 [PATCH RFC] io_uring: make signalfd work with io_uring (and aio) POLL Jens Axboe
2019-11-14  4:49 ` Jens Axboe
2019-11-14  9:19   ` Rasmus Villemoes [this message]
2019-11-14 13:46     ` Jann Horn
2019-11-14 14:12       ` Rasmus Villemoes
2019-11-14 15:09         ` Jens Axboe
2019-11-14 15:19           ` Rasmus Villemoes
2019-11-14 15:20             ` Jens Axboe
2019-11-14 15:27               ` Jens Axboe
2019-11-14 15:51                 ` Jens Axboe

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=ec3526fb-948a-70c0-4a7b-866d6cd6a788@rasmusvillemoes.dk \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox