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=-5.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS 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 C6F4FC2BB55 for ; Thu, 16 Apr 2020 01:37:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6142A20644 for ; Thu, 16 Apr 2020 01:37:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="K1LzI8rI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6142A20644 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B3DE48E006A; Wed, 15 Apr 2020 21:37:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC7218E0001; Wed, 15 Apr 2020 21:37:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98EFC8E006A; Wed, 15 Apr 2020 21:37:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 7A1588E0001 for ; Wed, 15 Apr 2020 21:37:52 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2F2C1824556B for ; Thu, 16 Apr 2020 01:37:52 +0000 (UTC) X-FDA: 76712006784.12.sea94_a7197fbb0611 X-HE-Tag: sea94_a7197fbb0611 X-Filterd-Recvd-Size: 6768 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 16 Apr 2020 01:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587001071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Q1wq3fmfPfnMeYZlpzXdKpMDd5i/pwrO+mtJdXRI6Cw=; b=K1LzI8rIzxhRUf+VcK5K6E3eFnGUKQ/j2v2uoNytbK1mEEW+JxHQ2DuzFddvj1AQ4s/D/Z PZheC+II0Zzx2HaJ2BcG+6LXpOAOq9VGHMsAwyo22/E7e6LUDE8BjMdlbHydkq9u4Hg0zN si9x0ms8hBigBcwpnCL7d58s5Io8PhM= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-236-dg7BmVswOfyl2oNRQdg3YQ-1; Wed, 15 Apr 2020 21:37:48 -0400 X-MC-Unique: dg7BmVswOfyl2oNRQdg3YQ-1 Received: by mail-qv1-f71.google.com with SMTP id es18so1904593qvb.9 for ; Wed, 15 Apr 2020 18:37:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=ZfkM9hUy9zY+sn22WstUWSEoLkl7MJxK53li2vbwwE8=; b=bXgURf+lTY+NWYqmxmUE9pMqzKOHlk6EkwMT5bFVaQB9w7aZc5wP0kfJu8Z/nib33j qAWgeEZzD0T1sels2QcafXuCqQR6WlieizC9lw53B6n2w44lhXpMErKCtu8/VPuHbwiM 5+ZYwkYrhkGoIBxI+7r1aaGPtgOVgjEhbkM3rXEGxGVs+8H8G9fQxVTkadx3t2YhDOLp dNym4QUAv19Tpc4K6NVBqR9h8Nr10fQWmWE+Lsir/x/Yzbhx5EsAf5PdgivMMbm0npPf 0rCKh/Lo5fX4HNp0Awc5vwLACp/3qBlV/5XTXQ0uFC85tpgHZwfnOTSolr+Szmi2IaBt PaSQ== X-Gm-Message-State: AGi0PubLqOZl+DjzTQlmB7MEeNscXttl35LLXxfQa21dvZ2vigzyfaJH NcW2uPYTvI7qLOWnrwvN3MF+BYmY7HCWJgkn8qaeKAJMOtkZhTfh+kxb9eTrh6tMDkmTlLAkqPS 7ez5JV6h7A6A= X-Received: by 2002:a37:4c0a:: with SMTP id z10mr29869989qka.408.1587001067616; Wed, 15 Apr 2020 18:37:47 -0700 (PDT) X-Google-Smtp-Source: APiQypKu25hAnhaOqxgMVvWBsBq179+ZUjbR20/zB2+uR1lrIRr4rItY+cn29bRqSm8w0u6rR1LxeA== X-Received: by 2002:a37:4c0a:: with SMTP id z10mr29869971qka.408.1587001067262; Wed, 15 Apr 2020 18:37:47 -0700 (PDT) Received: from xz-x1 ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id k35sm14857556qtc.28.2020.04.15.18.37.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 18:37:46 -0700 (PDT) Date: Wed, 15 Apr 2020 21:37:44 -0400 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 Message-ID: <20200416013744.GA230737@xz-x1> References: <20200414214516.GA182757@xz-x1> <20200415031602.22348-1-hdanton@sina.com> <20200415142546.GO5100@ziepe.ca> <20200416000229.GA9922@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: On Wed, Apr 15, 2020 at 06:15:26PM -0700, Brian Geffon wrote: > Hi Andrea, > Thanks for taking the time to reply. >=20 > > static int userfaultfd_flush(struct file *file, fl_owner_t id) > > { > > struct userfaultfd_ctx *ctx =3D file->private_data; > > wake_up_poll(&ctx->fd_wqh, EPOLLHUP); > > } > > >=20 > Yes, I think that something like this would work for this situation and e= ventfd. >=20 > > 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. >=20 > 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. >=20 > 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 >=20 > 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, --=20 Peter Xu