Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp429983yba; Mon, 1 Apr 2019 09:08:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqydWRFiQAhKmoPAXOAjYmr6Qph0b1f47GEgX0zxGocFBZx2N/wPBqEVcsTTpuGxNdbqiiPn X-Received: by 2002:a63:1d03:: with SMTP id d3mr61468421pgd.42.1554134939433; Mon, 01 Apr 2019 09:08:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554134939; cv=none; d=google.com; s=arc-20160816; b=O2j/8qYbxK+WwYtXzjdbFVIcHzrSDWCV5KKB3U01dgAjHYosxrMUXVDx1F8Elqu0IB sfIwuwrgqNkb2togaY2wprJAQJFhTAuh/dlQhERxxrwWtABESCay5WLGN0OFyHv7somw YxsP7NivXwXX0wl8yBc67bWIVIprfHbVlWYShLW8FpAJwGhq4SFtcRY3o29AjJD4sveZ mgld/c/EGAHnoDTZGdl2YAjEN1VBaaGgy4C7MrgDeUT9CjBJDvm0f0+sedyPfsRbGK4E ps3zPQr13lO7rdFrWRfYCiZUzyQ5PwcjISJv6vrnDtOCxbX3StkSIo7b9H1Js7LuVs34 oDEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=v2Qi25YX949jIc3McBjFS1Y0vROzQCOFEplzW4+lyGI=; b=ZyXAJviVZu3s8v25/vohdWSj2UBXCvWHsCvx6uvbwpoiOQTC9aMsLwHT6eJhAVHRxr bJ/jKB1CWv/XI9THvTN80KoA55tnOD5ovaeymQEVQrAFvd+j8XnrBhdZzdnAb3NaSrQo p/cHNzTlB+gdMRaoREgEEy4cqIEH1sX8JqGMQn7s1f3ws9F9lY0851uEzCDJpRjVfnoH EHfsyl3+q3ZD6r9V6KztR3yu+6uk8gB8z4VqmzWp+CvAGPyGp+vHe+2C/IohEZcbV7h/ YoC1RieIu6W6HO7s30RJJOtLa8fdYwPnZnU+2YvnGDu7vxPuMwHNa+CnYoGbx7AvcgvT bFiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PoI3dfat; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g59si9431609plb.281.2019.04.01.09.08.43; Mon, 01 Apr 2019 09:08:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PoI3dfat; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728627AbfDAQH7 (ORCPT + 99 others); Mon, 1 Apr 2019 12:07:59 -0400 Received: from mail-qt1-f194.google.com ([209.85.160.194]:37200 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726854AbfDAQH7 (ORCPT ); Mon, 1 Apr 2019 12:07:59 -0400 Received: by mail-qt1-f194.google.com with SMTP id z16so11514417qtn.4; Mon, 01 Apr 2019 09:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v2Qi25YX949jIc3McBjFS1Y0vROzQCOFEplzW4+lyGI=; b=PoI3dfatE77t8Hb18M/86sltYi695S8ACAUydXdWMi/YpBGlfJMxdDX9mM79VxmUcg 8IOX6vZZIRTncu4mG4VytQkbL5HWBTUbDifQ/9i/sEiYhYlYYuYU2xlrTJiJTx/Y2y50 JUoDtokWoSUExa3FNlu0vXP28X86pZI+un5NPVKVu8tEvBJV8PT1+r45wq1Pt9NoKf3K iZtVga2wKLDGffxZXE8ozb68HuYsYxfsxirIL4xdTR/lZRxKuK/He51nL1OJttkOMRtT 0bBo+McF4QfvVEEX89G1J/Yy+93PTLmR28Ea8L7cflBtBreDHicQ1SV+l2gPkcY+VFxV Gv2Q== 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=v2Qi25YX949jIc3McBjFS1Y0vROzQCOFEplzW4+lyGI=; b=ns4NbMSCxexcpxExBD9qjX1jOQ859AR8aeALIXiHT4/86uM3E+Vc5W5VzmmNZgWcbU YrsVPUXWO8UF3fY+p80RMQlPDWzpuWStPbBJFb7NxsN7ysyh7ajdbznrSOKklHqyUYK7 sSwb4sW9dgh/Yywlf8OJynwJYk+7j1DEP8AaQvub4fUuQS2L2GUl8eK5Zc3apeP2Uczv rLBSVXJ5AAhlgEIF5SdiLqFKb4okv9vDLIRu36E9suNOcKw0eOzgp0s3tyIuAZwyVbG8 NUY92nIwdhAZyRH1jlHyChsHCDnuVtAJ40j3cqk1Bn1kPVfPVBqTs/Sh6CyIaITsbLDz 9vDQ== X-Gm-Message-State: APjAAAW/jge9bDSs0tHpxS70r4ot5MI+vCFKnO/59yHy4gSsqE+rRw50 V15Qs87Hj9uusNRDUpdmOHBuzMdAHP1DGZXdF6BDig== X-Received: by 2002:ac8:2cd1:: with SMTP id 17mr53494503qtx.299.1554134877560; Mon, 01 Apr 2019 09:07:57 -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: Jonathan Kowalski Date: Mon, 1 Apr 2019 17:07:53 +0100 Message-ID: Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() To: Daniel Colascione Cc: Linus Torvalds , 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 , "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 4:55 PM Daniel Colascione wrote: > > On Mon, Apr 1, 2019 at 8:36 AM Linus Torvalds > wrote: > > > > On Mon, Apr 1, 2019 at 4:41 AM Aleksa Sarai wrote: > > > > > > Eric pitched a procfs2 which would *just* be the PIDs some time ago (in > > > an attempt to make it possible one day to mount /proc inside a container > > > without adding a bunch of masked paths), though it was just an idea and > > > I don't know if he ever had a patch for it. > > Couldn't this mode just be a relatively simple procfs mount option > instead of a whole new filesystem? It'd be a bit like hidepid, right? > The internal bind mount option and the no-dotdot-traversal options > also look good to me. > > > 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? > > > What are the *actual* use cases for opening /proc files through it? If > > it's really just for a small subset that android wants to do this > > (getting basic process state like "running" etc), rather than anything > > else, then we could skip the whole /proc linking entirely and go the > > other way instead (ie open_pidfd() would get that limited IO model, > > and we could make the /proc directory node get the same limited IO > > model). > > 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). Doing this work via pidfd > would be convenient. More generally, we can't enumerate the specific > use cases, because what we want to do with processes isn't bounded in > advance, and we regularly find new things in /proc/pid that we want to > read and write. I'd rather not prematurely limit the applicability of > the pidfd interface, especially when there's a simple option (the > procfs directory file descriptor approach) that doesn't require > in-advance enumeration of supported process inspection and > manipulation actions or a separate per-option pidfd equivalent. I very > much want a general-purpose API that reuses the metadata interfaces > the kernel already exposes. It's not clear to me how this rich > interface could be matched by read(2) on a pidfd. With the POLLHUP model on a simple pidfd, you'd know when the process you were referring to is dead (and one can map POLLPRI to dead and POLLHUP to zombie, etc). This is just an extension of the child process model, since you'd know when it's dead, there's no race involved with opening the wrong /proc/ entry. The entire thing is already non-racy for direct children, the same model can be extended to non-direct ones. This simplifies a lot of things, now I am essentially just passing a file descriptor pinning the struct pid associated with the original task, and not process state around to others (I may even want the other process to not read that stuff out even if it was allowed to, as it wouldn't have been able to otherwise, due to being a in a different mount namespace). KISS. The upshot is this same descriptor can be returned from clone, which would allow you to directly register it in your event loop (like signalfd, timerfd, file fd, sockets, etc) and POLLIN generated for you to read back its exit status (it is arguable if non-parents should be returned a readable instance from pidfd_open, but parents sure should). You can disable SIGCHLD for the child, and read back exit status much later. The entire point of waiting and reaping was that it'd be lost, but now you have a descriptor where it is kept for you to consume.