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=-13.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham 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 B2A0AC2D0EF for ; Thu, 16 Apr 2020 04:40:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 612EE20767 for ; Thu, 16 Apr 2020 04:40:08 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="EcJutLlh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 612EE20767 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D72C48E007A; Thu, 16 Apr 2020 00:40:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D230A8E0001; Thu, 16 Apr 2020 00:40:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C10EA8E007A; Thu, 16 Apr 2020 00:40:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0078.hostedemail.com [216.40.44.78]) by kanga.kvack.org (Postfix) with ESMTP id AAD4C8E0001 for ; Thu, 16 Apr 2020 00:40:07 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5C1994DC9 for ; Thu, 16 Apr 2020 04:40:07 +0000 (UTC) X-FDA: 76712466054.21.snail10_1069aeef4e06 X-HE-Tag: snail10_1069aeef4e06 X-Filterd-Recvd-Size: 6371 Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com [209.85.208.67]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Apr 2020 04:40:06 +0000 (UTC) Received: by mail-ed1-f67.google.com with SMTP id ca21so7580546edb.7 for ; Wed, 15 Apr 2020 21:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1TmAq26FwNb/+my3FNLYsjFmfOxy1GujQDz0h2Jw32I=; b=EcJutLlhow0uYQmo8crq4m4T0KDsDHGOBouftcX0wT4Y0o7bFLqgYyHUBSuHzqLdML BB/t6pjPuFQPd+ex7e9GH4Hzv4GOeochpK9O0XayObREuFm9JpqYqHJRZKrP/+CFkY2P RXujhkieLHZOsc8dQhSLobjzvNzkU6nmhCrt5NaZFCBJLGvdZUAt0KchwFBMCJC9IzoB NRzKTHEyu8uMPsm94Q+Fl9NSeulheLNEejw5G6wLIY5ygFYEnrWKFSpXL4aMgtnFUc6n O7Z5Bp5BzhXvLize3Jr5TZZJEEdjNZ9VU4VwAOUFxWe3lRHGVTO74K7NYCs6/ai9NCfw ++EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1TmAq26FwNb/+my3FNLYsjFmfOxy1GujQDz0h2Jw32I=; b=EuIQU7YqxTnMKTiKqgJF3W/ueTtbve3vw9jI5HJeWhPO6ymgM6vlek0IU3wnfkvaq2 y5RFiA9VOR8y9tm9R+MDVw5agUWCl37Huy2I8+sx0zr10DtxCFwM/c4fKdmAjAoazSG9 k44IJ6ONNAN9W0ML97M/30lBegdpFPY6Pl5uSTdDilvB0x9OMn8i9jKNsqxX4iPJtvdL K1soijBD0L5+GaCfzw2P+lY0uiVTfoOQG0FPz6pMRrdjIqavB/J4HGFz9ntHEfiF8sUN bypLPFKcyP4ucqEzns95pXDLq/8TkRi6wCidcbaU1s0+PvMWzDg1Si4nSXtuFb28uFpr 0lxg== X-Gm-Message-State: AGi0PuYGSOCY5Kut8hdsmA6bDCKFGj2EV6ucQpfOx46e2PXzjxx5qULA 0E8IAIRiPZuq54nFNn1pzi9yq8zgyfQfy3a172nYJA== X-Google-Smtp-Source: APiQypKuTs4ZTURfnwA3k9c3Sa6FarUnuNry42NNEmMYT4WoMaYpxBqdtlKm739fvWDGWqpS2PBNJmaOJbqjbj85g8Y= X-Received: by 2002:a05:6402:17aa:: with SMTP id j10mr27011118edy.146.1587012005301; Wed, 15 Apr 2020 21:40:05 -0700 (PDT) MIME-Version: 1.0 References: <20200414214516.GA182757@xz-x1> <20200415031602.22348-1-hdanton@sina.com> <20200415142546.GO5100@ziepe.ca> <20200416000229.GA9922@redhat.com> <20200416013744.GA230737@xz-x1> In-Reply-To: <20200416013744.GA230737@xz-x1> From: Brian Geffon Date: Wed, 15 Apr 2020 21:39:28 -0700 Message-ID: Subject: Re: Userfaultfd doesn't seem to break out of poll on fd close To: Peter Xu Cc: Andrea Arcangeli , Jason Gunthorpe , Hillf Danton , linux-mm , LKML , Sonny Rao Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 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 >