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, 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 00517C10F13 for ; Tue, 16 Apr 2019 19:21:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C21D62075B for ; Tue, 16 Apr 2019 19:20:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=joelfernandes.org header.i=@joelfernandes.org header.b="qjE2rB1W" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729538AbfDPTUy (ORCPT ); Tue, 16 Apr 2019 15:20:54 -0400 Received: from mail-pl1-f193.google.com ([209.85.214.193]:46834 "EHLO mail-pl1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728466AbfDPTUy (ORCPT ); Tue, 16 Apr 2019 15:20:54 -0400 Received: by mail-pl1-f193.google.com with SMTP id y6so10790193pll.13 for ; Tue, 16 Apr 2019 12:20:54 -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=TrAm6vZVRZkbHa9xfVw2z0t5FjVA5JjlGIUsDGc5sOM=; b=qjE2rB1WR7XMk2ceKl0pQM9EkxGpGGNT4K2yz89eJdvd2w0EkeGFMAmoy0pS/zS4AZ 1sDQnuHUtIBna7IAXrpnJjN0BufaymcEOovSF2ohlXLup7Zzgl0iZX4HAv1FPUfNmihQ Ds02YEstREl5Ot2TdtQa05RMtQWkCsldUu4xw= 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=TrAm6vZVRZkbHa9xfVw2z0t5FjVA5JjlGIUsDGc5sOM=; b=kxoCOuzTyzTJ68OoPXfpYVeUZ6ViAhEqXxXkW+EFnUdNHMmxgDoSCQ6Caww5MsOaqs 8l509ol7gFUSQwI8zvkjasT32yKiijupEJYHbJVVkBBAv4RmjU/D8PDxdFkn1XgX1SwW Ncx83xkRXFBVre58kzB3cZNxmddIdDaeIWEKXR9IaXa4xvL+8N1vwpaaozSJRQDkpevs JMC6B8oAmvGq56jXrqSzrHuA6AQeEM9Z20xQQ8vuvymNwpiHElk7U6PoYbBZQsqO4uYs 3L/hqqKiY0cEEufOrjeSJIqbO67RYf80eeGIFEr94U2bDGYCWB+rTjKoMgjKRT0DWIE/ KWAA== X-Gm-Message-State: APjAAAWvlm6Pu+C+1Nb50JXjyEDiy1pdjZvsUwZQuO7R59hwlw++VM8G xQuEjq3hlLDcjewRQeWz91beLQ== X-Google-Smtp-Source: APXvYqwyN1I+J2jXryJq7ybnAd8xb2bOtQ4rBzZDleoJkLn07KFlL1Tqt0Uef4o2G2NsP81KOqtQBA== X-Received: by 2002:a17:902:28ab:: with SMTP id f40mr63045912plb.297.1555442453472; Tue, 16 Apr 2019 12:20:53 -0700 (PDT) Received: from localhost ([2620:15c:6:12:9c46:e0da:efbf:69cc]) by smtp.gmail.com with ESMTPSA id f20sm40016503pff.176.2019.04.16.12.20.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 16 Apr 2019 12:20:52 -0700 (PDT) Date: Tue, 16 Apr 2019 15:20:51 -0400 From: Joel Fernandes To: Oleg Nesterov Cc: linux-kernel@vger.kernel.org, luto@amacapital.net, rostedt@goodmis.org, dancol@google.com, christian@brauner.io, jannh@google.com, surenb@google.com, torvalds@linux-foundation.org, Alexey Dobriyan , Al Viro , Andrei Vagin , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, Michal Hocko , Nadav Amit , Serge Hallyn , Shuah Khan , Stephen Rothwell , Taehee Yoo , Tejun Heo , Thomas Gleixner , kernel-team@android.com, Tycho Andersen Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd Message-ID: <20190416192051.GA184889@google.com> References: <20190411175043.31207-1-joel@joelfernandes.org> <20190416120430.GA15437@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190416120430.GA15437@redhat.com> 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 Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote: > On 04/11, Joel Fernandes (Google) wrote: > > > > +static unsigned int proc_tgid_base_poll(struct file *file, struct poll_table_struct *pts) > > +{ > > + int poll_flags = 0; > > + struct task_struct *task; > > + struct pid *pid; > > + > > + task = get_proc_task(file->f_path.dentry->d_inode); > > + > > + WARN_ON_ONCE(task && !thread_group_leader(task)); > > + > > + /* > > + * tasklist_lock must be held because to avoid racing with > > + * changes in exit_state and wake up. Basically to avoid: > > + * > > + * P0: read exit_state = 0 > > + * P1: write exit_state = EXIT_DEAD > > + * P1: Do a wake up - wq is empty, so do nothing > > + * P0: Queue for polling - wait forever. > > + */ > > + read_lock(&tasklist_lock); > > + if (!task) > > + poll_flags = POLLIN | POLLRDNORM | POLLERR; > > + else if (task->exit_state == EXIT_DEAD) > > + poll_flags = POLLIN | POLLRDNORM; > > + else if (task->exit_state == EXIT_ZOMBIE && thread_group_empty(task)) > > + poll_flags = POLLIN | POLLRDNORM; > > + > > + if (!poll_flags) { > > + pid = proc_pid(file->f_path.dentry->d_inode); > > + poll_wait(file, &pid->wait_pidfd, pts); > > + } > > can't understand... > > Could you explain when it should return POLLIN? When the whole process exits? It returns POLLIN when the task is dead or doesn't exist anymore, or when it is in a zombie state and there's no other thread in the thread group. > Then all you need is > > !task || task->exit_state && thread_group_empty(task) Yes this works as well, all the tests pass with your suggestion so I'll change it to that. Although I will the be giving up returing EPOLLERR if the task_struct doesn't exit. We don't need that, but I thought it was cool to return it anyway. > Please do not use EXIT_DEAD/EXIT_ZOMBIE. And ->wait_pidfd should probably > live in task->signal_struct. About wait_pidfd living in signal_struct, that wont work since the waitqueue has to survive for the duration of the poll system call. Linus also confirmed this: https://lore.kernel.org/patchwork/patch/1060650/#1257371 Also the waitqueue living in struct pid solves the de_thread() issue I mentioned later in the following thread and in the commit message: https://lore.kernel.org/patchwork/comment/1257175/ thanks, - Joel