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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL 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 67CC0C10F0E for ; Thu, 18 Apr 2019 17:53:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A75B217D7 for ; Thu, 18 Apr 2019 17:53:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SVcgtSBL" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389056AbfDRRxr (ORCPT ); Thu, 18 Apr 2019 13:53:47 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:41609 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388299AbfDRRxq (ORCPT ); Thu, 18 Apr 2019 13:53:46 -0400 Received: by mail-vs1-f65.google.com with SMTP id g187so1617080vsc.8 for ; Thu, 18 Apr 2019 10:53:46 -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=+aCB51wSzBRb+g6w79GERBDmxHkdK0m0brStvsO0x24=; b=SVcgtSBLmc2xM0J5DquLhMFb3hyfz4jZTgTJA9db/Q8DtxuxUWeCly6ndSd7MftMTo QSxPEAq4uZJkuDwesNVjJGjqmFdzN6buw4++xszB5VkqtCrdrpX9PieeYFgpI96cXT45 KXQIMoPCG8r/4kLJ+982MtD6FxhXq+tNQPbV781ZYkeXwRkVr0ysQEwRPekTwrcD5x07 SG5s+UWiaynVqfgkx5W66M0NiitSqBM7uZmj/7Dhv6noOVotqh8WVRNN+ThVMo065w6T ljotwg4tXAZEcg+fOmJM3yf8jBBMUVSb1ZU/FGvZVS62zlKzO3C3t/uYTBoME2J/VhkP YkFg== 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=+aCB51wSzBRb+g6w79GERBDmxHkdK0m0brStvsO0x24=; b=EMAlYDrspZFafAGImr2VAcCRIr3Y4Wnf0OOqZdaY7aw4G6/qa0tOtbaPN2tcQhdgfz EMMogtkxcQM9AXTn4IlNUb75/uDUyJ8HWzambF53DPjGlKRb4HWzdp6Qa0FmIi5qPia5 5WOoVvLgqXh2jS/GyI3Vl3F7dAap25vSuiP/Dlz5+FvXuxAgxs9QLWV80N16eAJfUwsG pOUTgfIQVKI/B3jJvtlFIGpEcqbg1KpwU3YpsvXQ4y9JgmpQBmZc/JbarJC6rbX3HpnE 9joDPuf/4aW4dzMRkDMCMTjhbGN4tnAst9cackp7lBIrPxP2J6kT/bZ3P+9g9p88vjRj 1SHg== X-Gm-Message-State: APjAAAV5hQZpiBSqQO4UdbzBYhNeqSp4PgzNwIzRGXSDm4+X5r2TdIyp S8gL3RigReqImd8KpFIgpS/lbWxtqgBh10kI6m7ABQ== X-Google-Smtp-Source: APXvYqzHYvVcAcOQAwnRLj6YgPyJZ7DIOcssgUOygTW1U3l1rCQmKILucHf0R9Ig/AIM9bDZMr/6LQyMo2j+hWPp2EU= X-Received: by 2002:a05:6102:18d:: with SMTP id r13mr55413741vsq.171.1555610025262; Thu, 18 Apr 2019 10:53:45 -0700 (PDT) MIME-Version: 1.0 References: <20190411175043.31207-1-joel@joelfernandes.org> <20190416120430.GA15437@redhat.com> <20190416192051.GA184889@google.com> <20190417130940.GC32622@redhat.com> In-Reply-To: From: Daniel Colascione Date: Thu, 18 Apr 2019 10:53:33 -0700 Message-ID: Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd To: Christian Brauner Cc: Jann Horn , Oleg Nesterov , Joel Fernandes , Florian Weimer , kernel list , Andy Lutomirski , Steven Rostedt , Suren Baghdasaryan , Linus Torvalds , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Apr 18, 2019 at 10:26 AM Christian Brauner wrote: > > On April 18, 2019 7:23:38 PM GMT+02:00, Jann Horn wrote: > >On Wed, Apr 17, 2019 at 3:09 PM Oleg Nesterov wrote: > >> On 04/16, Joel Fernandes wrote: > >> > On Tue, Apr 16, 2019 at 02:04:31PM +0200, Oleg Nesterov wrote: > >> > > > >> > > 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. > >> > >> IOW, when the whole thread group exits, so it can't be used to > >monitor sub-threads. > >> > >> just in case... speaking of this patch it doesn't modify > >proc_tid_base_operations, > >> so you can't poll("/proc/sub-thread-tid") anyway, but iiuc you are > >going to use > >> the anonymous file returned by CLONE_PIDFD ? > > > >I don't think procfs works that way. /proc/sub-thread-tid has > >proc_tgid_base_operations despite not being a thread group leader. Huh. That seems very weird. Is that too late to change now? It feels like a bug. > >(Yes, that's kinda weird.) AFAICS the WARN_ON_ONCE() in this code can > >be hit trivially, and then the code will misbehave. > > > >@Joel: I think you'll have to either rewrite this to explicitly bail > >out if you're dealing with a thread group leader If you're _not_ dealing with a leader, right? > , or make the code > >work for threads, too. > The latter case probably being preferred if this API is supposed to be useable for thread management in userspace. IMHO, focusing on the thread group case for now might be best. We can always support thread management in future work. Besides: I'm not sure that we need kernel support for thread monitoring. Can't libc provide a pollable FD for a thread internally? libc can always run code just before thread exit, and it can wake a signalfd at that point. Directly terminating individual threads without going through userland is something that breaks the process anyway: it's legal and normal to SIGKILL a process a whole, but if an individual thread terminates without going through libc, the process is likely going to be fatally broken anyway. (What if it's holding the heap lock?) I know that in some tools want to wait for termination of individual threads in an external monitored process, but couldn't these tools cooperate with libc to get these per-thread eventfds? Is there a use case I'm missing?