archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <>
To: Brian Geffon <>
Cc: Andrea Arcangeli <>,
	Jason Gunthorpe <>, Hillf Danton <>,
	linux-mm <>,
	LKML <>,
	Sonny Rao <>
Subject: Re: Userfaultfd doesn't seem to break out of poll on fd close
Date: Wed, 15 Apr 2020 21:37:44 -0400	[thread overview]
Message-ID: <20200416013744.GA230737@xz-x1> (raw)
In-Reply-To: <>

On Wed, Apr 15, 2020 at 06:15:26PM -0700, Brian Geffon wrote:
> Hi Andrea,
> Thanks for taking the time to reply.
> > static int userfaultfd_flush(struct file *file, fl_owner_t id)
> > {
> >         struct userfaultfd_ctx *ctx = file->private_data;
> >         wake_up_poll(&ctx->fd_wqh, EPOLLHUP);
> > }
> >
> Yes, I think that something like this would work for this situation and eventfd.
> > If eventfd and pipes all behave identical to uffd (they should as they
> > don't seem to implement flush) I'm not sure if there's good enough
> > justification to deviate from the default VFS behavior here.
> Pipes actually behave a little differently, in the case that you close
> the write end of the pipe the read end will break out of the poll with
> EPOLLHUP, but I suppose closing the read end while the read end is
> being polled would be more analogous to what I'm describing here. And
> this is why it felt weird to me, in these situations the kernel
> _knows_ that after the close nothing can happen on the file
> descriptor, so what's the point of keeping it in a poll? As soon as
> the poll breaks any read, write, ioctl, etc on the fd whether it's a
> userfaultfd or an eventfd would fail with -EBADF.
> 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:
> For my use case adding an eventfd on poll works well, so thank you for
> that suggestion. But the behavior just seemed odd to me which is why I
> started this thread.

Hi, Brian,

I think I can understand you on the weirdness when comparing to the
pipes.  And IIUC that's majorly what POLLHUP is used for - it tells us
that the channel has closed.  I believe it's the same to a pair of
send/recv sockets when one end closes the port so the other side can
get a POLLHUP.

However IMO userfaultfd is not such a channel like pipes, as you have
already mentioned.  It's not paired ports.  As you've given the other
example on "closing the read pipe when reading the read pipe" - I'm
curious what will happen for that.  I feel like it'll happen the same
way as being blocked, just like what userfaultfd and eventfd are
doing.  My understanding is that the Linux kernel should be thread
safe on all these operations so no matter how we use the syscalls and
in what order the kernel shouldn't break with this.  However IMHO it
does not mean that it'll guarantee things like "close() will kick all
existing fd operations".  I don't know whether there's any restriction
in POSIX or anything for this, but... I won't be too surprised if
someone tells me there's some OS that will directly crash the process
if one fd is close()ed during a read()...


Peter Xu

  reply	other threads:[~2020-04-16  1:37 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 [this message]
2020-04-16  4:39             ` Brian Geffon
2020-04-16 14:49           ` Jason Gunthorpe

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:

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

  git send-email \
    --in-reply-to=20200416013744.GA230737@xz-x1 \ \ \ \ \ \ \ \ \

* 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).