linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Brian Geffon <bgeffon@google.com>
To: Peter Xu <peterx@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Hillf Danton <hdanton@sina.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: Wed, 15 Apr 2020 21:39:28 -0700	[thread overview]
Message-ID: <CADyq12w3zO9iFPhCMzX=QXM88bvWjRUVdrbV637a-1Mwjvxp9w@mail.gmail.com> (raw)
In-Reply-To: <20200416013744.GA230737@xz-x1>

Thanks Peter,
I see your point. I'm totally fine if we just leave this at: just
don't do it. lol. I appreciate you guys taking the time to talk
through this.

Brian



Brian

On Wed, Apr 15, 2020 at 6:37 PM Peter Xu <peterx@redhat.com> wrote:
>
> 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:
> > https://gist.github.com/bgaff/607302d86d99ac539efca307ce2dd679
> >
> > 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()...
>
> Thanks,
>
> --
> Peter Xu
>


  reply	other threads:[~2020-04-16  4:40 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 [this message]
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:
  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='CADyq12w3zO9iFPhCMzX=QXM88bvWjRUVdrbV637a-1Mwjvxp9w@mail.gmail.com' \
    --to=bgeffon@google.com \
    --cc=aarcange@redhat.com \
    --cc=hdanton@sina.com \
    --cc=jgg@ziepe.ca \
    --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).