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=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 98501C43381 for ; Mon, 1 Apr 2019 16:13:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5882B21473 for ; Mon, 1 Apr 2019 16:13:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Lyf0Ue09" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728678AbfDAQNz (ORCPT ); Mon, 1 Apr 2019 12:13:55 -0400 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38878 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727190AbfDAQNz (ORCPT ); Mon, 1 Apr 2019 12:13:55 -0400 Received: by mail-oi1-f193.google.com with SMTP id a6so4367969oie.5 for ; Mon, 01 Apr 2019 09:13:55 -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=ZWpt8sWnrUp7nM/XGIxo9u0cVgp4+vUOvus+dJto+50=; b=Lyf0Ue09Nd1tOatU42yL8u7cpj+p/6td+bwqcCBNgda8mW7BcPrSF/2hMbWzSoGBR4 MCRX+Bpig/u6MqFN+/mh0akFJu5bBddwU9maL9LoJpFtw6YjiaZn8Dn3vPtVw436Cm0S dUG9gAQWCBuEyhJ+ETb2zv1yamz30ss3c1YamCEXuC85vL/a9tdGNtnCfoFmRmj+yyTw DJLA4gkEiIgEgFrg9dYy3eoozyX76If68TGbYTznZ+aor6lIDq1ITvDaYod630Iisg6o pIK71zGak5EqVNXaKkheOwcEWpPI4pxxAEOznhQ+b520XdgCUrrepqlmDXZLIsatLd7W dQUg== 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=ZWpt8sWnrUp7nM/XGIxo9u0cVgp4+vUOvus+dJto+50=; b=Z85fZp6bMGseqSYOKyjugOt0y5C8/mqnANUWIaRmvaqYyHW8S+eGU31pbbpALalWB3 Hj0uTFq8dtwFXYf/juFAc8avEGsUGQvSy4qtntvOQYhF1NAgfj/Eoy2Uca7k0JEySB/J unPkOCAqmYGZXHj9IIDfZiXH21dzOcnBHeyWSCqZRXY6iO+6/EMcoNDHytHvhmfdPRUh UPRiGXACqPz9I8U/Gykgkvd5RWXoa6I5RlllZxOIxNpM8+OYF5N3Nr+knvA5klV8GFyN SnZoeqOyNPTbhjKFnAKNid1wexEpYGv7XaEW1hUSx8iScNhG2OKUHN3la8+npwN3qQTj yMFQ== X-Gm-Message-State: APjAAAW/cL1JK1BK8DOnMNDB8ibBRS0e/y1HS4FqM60/8l8ihJ6nECJn UFzcXrfEACewAcWsUqVTLCYLyzCqWja3VqBEZG36Yw== X-Google-Smtp-Source: APXvYqzFW2OG+7HDYpoLMJensdtGtgLIhfTx1IksXFq/Qc3DaxB8AxBTKFJS34bbAay/8LeqGTv/ODfzRP8nNrFuBfs= X-Received: by 2002:aca:550c:: with SMTP id j12mr13767315oib.52.1554135234224; Mon, 01 Apr 2019 09:13:54 -0700 (PDT) MIME-Version: 1.0 References: <20190330171215.3yrfxwodstmgzmxy@brauner.io> <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> <20190401114059.7gdsvcqyoz2o5bbz@yavin> In-Reply-To: From: Daniel Colascione Date: Mon, 1 Apr 2019 09:13:42 -0700 Message-ID: Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() To: Linus Torvalds Cc: Aleksa Sarai , Andy Lutomirski , Christian Brauner , Jann Horn , Andrew Lutomirski , David Howells , "Serge E. Hallyn" , Linux API , Linux List Kernel Mailing , Arnd Bergmann , "Eric W. Biederman" , Konstantin Khlebnikov , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton , Oleg Nesterov , Nagarathnam Muthusamy , Al Viro , Joel Fernandes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 1, 2019 at 9:01 AM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote: > > > > > > > I wonder if we really want a fill procfs2, or maybe we could just make > > > the pidfd readable (yes, it's a directory file descriptor, but we > > > could allow reading). > > > > What would read(2) read? > > We could make it read anything, but it would have to be something > people agree is sufficient (and not so expensive to create that rare > users of that data would find the overhead excessive). In my exithand patch last year, I took a minimal approach and just had read(2) read EOF once the process exited and blocked until then. Maybe we could do that? But if we're supported waitid(2) on pidfds instead, then we don't need read(2) at all on pidfds, right? Right now, I don't see a situation in which I'd take advantage of a pidfd read(2) that just gave me the running/sleeping/zombie state. I'm also a bit worried about the implications of making a directory FD also readable. Didn't problems with that come up in one of the multiple-named-streams proposals? > Eg we could make it return the same thing that /proc//status > reads right now. > > But it sounds like you need pretty much all of /proc//xyz: > > > We do a lot of process state inspection and manipulation, including > > reading and writing the oom killer adjustment score, reading smaps, > > and the occasional cgroup manipulation. More generally, I'd also like > > to be able to write a race-free pkill(1) > > I suspect most of what pkill wants is indeed in that 'status' file, > but other things aren't. Right. It's hard to predict what we might need. pkill also needs /proc/pid/cmdline, FWIW. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Colascione Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() Date: Mon, 1 Apr 2019 09:13:42 -0700 Message-ID: References: <20190330171215.3yrfxwodstmgzmxy@brauner.io> <132107F4-F56B-4D6E-9E00-A6F7C092E6BD@amacapital.net> <20190331211041.vht7dnqg4e4bilr2@brauner.io> <18C7FCB9-2CBA-4237-94BB-9C4395A2106B@amacapital.net> <20190401114059.7gdsvcqyoz2o5bbz@yavin> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Torvalds Cc: Aleksa Sarai , Andy Lutomirski , Christian Brauner , Jann Horn , Andrew Lutomirski , David Howells , "Serge E. Hallyn" , Linux API , Linux List Kernel Mailing , Arnd Bergmann , "Eric W. Biederman" , Konstantin Khlebnikov , Kees Cook , Alexey Dobriyan , Thomas Gleixner , Michael Kerrisk-manpages , Jonathan Kowalski , "Dmitry V. Levin" , Andrew Morton List-Id: linux-api@vger.kernel.org On Mon, Apr 1, 2019 at 9:01 AM Linus Torvalds wrote: > > On Mon, Apr 1, 2019 at 8:55 AM Daniel Colascione wrote: > > > > > > > I wonder if we really want a fill procfs2, or maybe we could just make > > > the pidfd readable (yes, it's a directory file descriptor, but we > > > could allow reading). > > > > What would read(2) read? > > We could make it read anything, but it would have to be something > people agree is sufficient (and not so expensive to create that rare > users of that data would find the overhead excessive). In my exithand patch last year, I took a minimal approach and just had read(2) read EOF once the process exited and blocked until then. Maybe we could do that? But if we're supported waitid(2) on pidfds instead, then we don't need read(2) at all on pidfds, right? Right now, I don't see a situation in which I'd take advantage of a pidfd read(2) that just gave me the running/sleeping/zombie state. I'm also a bit worried about the implications of making a directory FD also readable. Didn't problems with that come up in one of the multiple-named-streams proposals? > Eg we could make it return the same thing that /proc//status > reads right now. > > But it sounds like you need pretty much all of /proc//xyz: > > > We do a lot of process state inspection and manipulation, including > > reading and writing the oom killer adjustment score, reading smaps, > > and the occasional cgroup manipulation. More generally, I'd also like > > to be able to write a race-free pkill(1) > > I suspect most of what pkill wants is indeed in that 'status' file, > but other things aren't. Right. It's hard to predict what we might need. pkill also needs /proc/pid/cmdline, FWIW.