linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Brian Geffon <bgeffon@google.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Hillf Danton <hdanton@sina.com>, Peter Xu <peterx@redhat.com>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Sonny Rao <sonnyrao@google.com>
Subject: Re: Userfaultfd doesn't seem to break out of poll on fd close
Date: Thu, 16 Apr 2020 11:49:42 -0300	[thread overview]
Message-ID: <20200416144942.GQ5100@ziepe.ca> (raw)
In-Reply-To: <CADyq12xg8vxetG8y=M6i2m4qYrtjsRhmpds-3yKTY2icrHG2GA@mail.gmail.com>

On Wed, Apr 15, 2020 at 06:15:26PM -0700, Brian Geffon wrote:

> And all of that I guess makes sense in the case of a non-blocking fd,
> but what about the case of a blocking file descriptor? Both
> userfaultfd and eventfd can seemingly be stuck in a read syscall with
> no way to break them out when the userfaultfd/eventfd has no further
> utility. Here is an example:
> https://gist.github.com/bgaff/607302d86d99ac539efca307ce2dd679

If an application wants to terminate blocking calls it has to rely on
signal delivery or pthread_cancel to end it.

This is very complicated so it is generally better to use poll and non
blocking.

Jason


      parent reply	other threads:[~2020-04-16 14:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-12 20:10 Userfaultfd doesn't seem to break out of poll on fd close Brian Geffon
2020-04-14 21:45 ` Peter Xu
2020-04-14 22:34   ` Jason Gunthorpe
2020-04-15  3:16   ` Hillf Danton
2020-04-15 14:25     ` Jason Gunthorpe
2020-04-15 15:16       ` Brian Geffon
2020-04-16  0:02       ` Andrea Arcangeli
2020-04-16  1:15         ` Brian Geffon
2020-04-16  1:37           ` Peter Xu
2020-04-16  4:39             ` Brian Geffon
2020-04-16 14:49           ` Jason Gunthorpe [this message]

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=20200416144942.GQ5100@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=aarcange@redhat.com \
    --cc=bgeffon@google.com \
    --cc=hdanton@sina.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=sonnyrao@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).