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=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 E454CC282E2 for ; Sat, 20 Apr 2019 00:47:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A857D2183F for ; Sat, 20 Apr 2019 00:47:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="wSdZMzhK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726126AbfDTArB (ORCPT ); Fri, 19 Apr 2019 20:47:01 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:44558 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbfDTArB (ORCPT ); Fri, 19 Apr 2019 20:47:01 -0400 Received: by mail-pl1-f194.google.com with SMTP id y12so671182plk.11 for ; Fri, 19 Apr 2019 17:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=lJeJCEsvjqX5rGVJW/HifUv3RwhSjNdHLvuBe2kGGfU=; b=wSdZMzhKAmXWG+c9nxI1Ty9OEoHWhIECkuhxH3mr4CfZGPhKu+43CIdbUmWjaHFNPN a4iDaM9ERZujhMePnXrwwGOTOIn+Iel8E4QAXJfWq2VqhCHHcQVA2EWiYAdUcfJugZxt iUzsd2EFp378t7EixJw76/OIwIrt3puPV7NuE= 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:user-agent; bh=lJeJCEsvjqX5rGVJW/HifUv3RwhSjNdHLvuBe2kGGfU=; b=UwKzwmtlfNMm2e9+bmSqpmvgMwNXV2H2pIx2+usqOILm8ncjuW/4xF5TROF/v7M18u 2MGvDGKaLp6tu7QdXjO+jWOIdSkR6gpUEZCCzw+nn2hds/QGsJopd+nUApSnJYnqA6YA GiGwIZiQLbu47RBze1Y3DZeIjOk0pygOxS/1AZFlw2Z/A6GbM7ZicS5HMMQIw8TQt6DY mmEM60yZp6RDcSAX+Lv3gz6p8x7Eb9g9+hsF6FB2i5qsZNPWoJHX1Eq0MG0v1BO+sCXP hfogvAKG1mS5Dpe1EcHpr0C4woaGp7l+wunpi8luVtE6Wt8mhNG+SiLXQGBGk1SRpiTD L76Q== X-Gm-Message-State: APjAAAXi+ZcVfZ6KJvCc9+lVutIwU+dsrIQM85pqtMga4NjkP+TFVPWc n7hH01LxkZE71Ne/wY6O9N3ttA== X-Google-Smtp-Source: APXvYqxfATsHcB4e2dILvIrcj7CiKIpV6NhIpgkeRV7u+EE3NNbOror1y4PJCT6woCZacJ/MaSsKlg== X-Received: by 2002:a17:902:3064:: with SMTP id u91mr6507760plb.181.1555721220670; Fri, 19 Apr 2019 17:47:00 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id u4sm433524pgr.89.2019.04.19.17.46.58 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Apr 2019 17:46:59 -0700 (PDT) Date: Fri, 19 Apr 2019 20:46:58 -0400 From: Joel Fernandes To: Linus Torvalds Cc: Christian Brauner , Daniel Colascione , Jann Horn , Oleg Nesterov , Florian Weimer , kernel list , Andy Lutomirski , Steven Rostedt , Suren Baghdasaryan , Alexey Dobriyan , Al Viro , Andrei Vagin , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , linux-fsdevel , "open list:KERNEL SELFTEST FRAMEWORK" , Michal Hocko , Nadav Amit , Serge Hallyn , Shuah Khan , Stephen Rothwell , Taehee Yoo , Tejun Heo , Thomas Gleixner , kernel-team , Tycho Andersen Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd Message-ID: <20190420004658.GG251571@google.com> References: <20190417130940.GC32622@redhat.com> <20190419190247.GB251571@google.com> <20190419191858.iwcvqm6fihbkaata@brauner.io> <20190419194902.GE251571@google.com> <20190419212002.GB44851@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, Apr 19, 2019 at 04:11:37PM -0700, Linus Torvalds wrote: > On Fri, Apr 19, 2019 at 2:20 PM Joel Fernandes wrote: > > > > According to Linus, POLLHUP usually indicates that something is readable: > > Note that if you use the legacy interfaces (ie "select()"), then even > just a plain POLLHUP will always just show as "readable". > > So for a lot of applications, it won't even matter. Returning POLLHUP > will mean it's readable whether POLLIN is set or not (and EPOLLERR > will automatically mean that it's marked both readable and writable). > > In fact, I'd argue that not a lot of people care about the more > esoteric bits at all. If your poll function does POLLIN and POLLOUT, > it's fine. Anything else is specialized enough that most people simply > won't care. Don't overdesign things too much. You need to have a major > reason to care about the other POLL bits. > > It's also worth noting that POLLERR/POLLHUP/POLLNVAL cannot be masked > for "poll()". Even if you only ask for POLLIN/POLLOUT, you will always > get POLLERR/POLLHUP notification. That is again historical behavior, > and it's kind of a "you can't poll a hung up fd". But it once again > means that you should consider POLLHUP to be something *exceptional* > and final, where no further or other state changes can happen or are > relevant. > > That may well work fine for pidfd when the task is gone, but it's > really worth noting that any *normal* state should be about > POLLIN/POLLOUT. People should not think that "POLLHUP sounds like the > appropriate name", they should realize that POLLHUP is basically a > terminal error condition, not a "input is available". > > So just keep that in mind. Got it, thanks a lot for the detailed explanation of the flags. So then I feel I should not return POLLHUP or POLLERR because the task_struct getting reaped is not an error condition. I will simplify the patch and repost it. It seems that would be the best thing to do to serve the usecase. We just want to know when the task exited and a reaped task also counts as one that exited. thanks, - Joel