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 943C9C2BA19 for ; Thu, 16 Apr 2020 01:16:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3FE502076D for ; Thu, 16 Apr 2020 01:16:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="rFyRARAR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FE502076D 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 CAD948E0062; Wed, 15 Apr 2020 21:16:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5E378E0001; Wed, 15 Apr 2020 21:16:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B749B8E0062; Wed, 15 Apr 2020 21:16:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0090.hostedemail.com [216.40.44.90]) by kanga.kvack.org (Postfix) with ESMTP id 9D4578E0001 for ; Wed, 15 Apr 2020 21:16:05 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5D979181AEF23 for ; Thu, 16 Apr 2020 01:16:05 +0000 (UTC) X-FDA: 76711951890.12.party87_6f56e0ab4a60b X-HE-Tag: party87_6f56e0ab4a60b X-Filterd-Recvd-Size: 4549 Received: from mail-ed1-f68.google.com (mail-ed1-f68.google.com [209.85.208.68]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Apr 2020 01:16:04 +0000 (UTC) Received: by mail-ed1-f68.google.com with SMTP id s29so7395936edc.1 for ; Wed, 15 Apr 2020 18:16:04 -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=DqhZGRoL70sm5/RzVHO716gnr2CLOKeQ+jLS9k1/y4Y=; b=rFyRARARoNvifTie3IBinXaGw3HxWbMokaBEk9FRXHKnN2o9HQhSGjBCrKKdNUYv+q ySccDKON48Kn5CX1Hb2xKb3O+fhncJOjdCjC0t2l1Q6XCKyMahaZUP34nUWaFw0LiVI9 r3pjyTURPGWopwqma4Z6YJa5jtcZf1Bz+K56h45IUS205NJ3gScZV0yC5wQSyQ8z50l1 Gvin7IoCG734F0kcIVUghxfJXGxvt9U2omfAFExwvrNieQpeK98ioL52hWBJ5aGWexXy 3kD1KIFDI5I4GMiAAQlLfEpqutRTj6lMTdeNaJftbg1z01fnoFuiQqpeAYHnmay+F6J9 rd/g== 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=DqhZGRoL70sm5/RzVHO716gnr2CLOKeQ+jLS9k1/y4Y=; b=douTdbLoYyTL3GebR73T4oU3GkSOX6Va1k4NFpxOxifSketEH+x8qnW0hjYYZHZxSP 0dsBKM5sfeNnYhLbcUpXn2PiWmFWTZ4Rx3G7HwVi2/XxO2LcT+KEMOUqPoiE+sOo711M MbMcL2Ja/eCzvH0Qg2pHnkWvbGNe3JuI6yTyN2Hta/oHYBfjImcKT2vCWdS2WalOvcQt b/yjjYkF7HjCvhV0SixAsY8BV2Bn/r19iIlulAuVFNyxKXi+q81KiLUthGCxiDZxQcF8 VqvGx94eUbukjbWaorzn79RweAQOlyrFTAkxjJHdFW7vFVj3kUJnIqIhi2u0N73qGB/q HZHQ== X-Gm-Message-State: AGi0PuZ+JLQsDTOB6YOA9+v+aNZTfzqrCj+Nnov3tQS+SlTPK5HxS0G2 y0XK+9nXAWb/Ao/WznFbfa+MbESFvfKGzi2khZWLUg== X-Google-Smtp-Source: APiQypJdK40vPIhcswQ8xkik3AhhbZAYcvE2Hh6OIrvYJSqpheM1v+mhi3nUTHnpQhjxo0F4dTdt0+eK0N4jSjhfODc= X-Received: by 2002:a50:a9c5:: with SMTP id n63mr27903084edc.312.1586999763505; Wed, 15 Apr 2020 18:16:03 -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> In-Reply-To: <20200416000229.GA9922@redhat.com> From: Brian Geffon Date: Wed, 15 Apr 2020 18:15:26 -0700 Message-ID: Subject: Re: Userfaultfd doesn't seem to break out of poll on fd close To: Andrea Arcangeli Cc: Jason Gunthorpe , Hillf Danton , Peter Xu , linux-mm , LKML , Sonny Rao Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000013, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. Thanks, Brian