Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp2661731ybb; Sat, 30 Mar 2019 10:25:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqxyIANoxBcZ67QvQ102ZTaSVbUItwSlVDq/UdS7yyNpYgmOkeb3CBvuk+94YfO18M8CGvFt X-Received: by 2002:a17:902:9a5:: with SMTP id 34mr55957370pln.287.1553966731968; Sat, 30 Mar 2019 10:25:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553966731; cv=none; d=google.com; s=arc-20160816; b=HOqpNU40veNZe3HIrUf1qSCZZGFNB6wkKUVjSPOLWDotzFcVsS/COFizp8ivGNGbwO 9kP8wbUvbdqMdV8UfXjSR4MMelIvOrwidIdrut9jsmLkoKV9WTGTTZMspgWrZRERQb9E vkVZHJntVCXVSjvSvmbLxihLEIcgnwRDao+eX0RKTQSQMD15s3DfDMBzaCyYzwdND5Vm l6kPtY+SECoNKK9BDGPGfVNPY/jaOu89LYDsnTDqEpeaaf+86nt3BVtTPw/N7lYLnaAU lhPQ+KpIpXyiepR8bnRwxTtL0vIbvpiVqL0ka2dw4V0fqqxApY2OtYg2OIchMzv1ngNL BDAQ== 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=beyhB6lVljywyNB9oOMjClZFho1egNhaGdBfwfOVZJk=; b=pdN7Tn/abjrSCbLI+SG6OcHCEB3x/hRWsBg7mYC7MArRFkQF6LJx/aDQN8Ol5jY9HQ gqsHVvB3/6j7kqIkvjHM/1yOaiXkxgk8zp5q/lCE46pZqedVO3O+WLaJdyVoX6JMY6D8 J55GCwWpBI0hjG2l5P8s4LG1l6vAp52BjZuh+tR8EFDC+AeeOnivCCb8miXrbLFRTXnf qjQHBnFMBxqxgUruwh4hcvw2Kv/L2a5/Mo+0sEUONLk5FmuPJYbX4pTAt6icZlYjhde9 gk/So0iwXIimM93NhUqrRYRItpFw8ntzo9YEIBMBas1EJF9cfncrtCbDmscCMiRHhRS9 nmiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=HNLe0b3z; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j19si1006204pfh.147.2019.03.30.10.25.16; Sat, 30 Mar 2019 10:25:31 -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=@linux-foundation.org header.s=google header.b=HNLe0b3z; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730671AbfC3RYk (ORCPT + 99 others); Sat, 30 Mar 2019 13:24:40 -0400 Received: from mail-lj1-f196.google.com ([209.85.208.196]:45979 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730477AbfC3RYk (ORCPT ); Sat, 30 Mar 2019 13:24:40 -0400 Received: by mail-lj1-f196.google.com with SMTP id y6so4552871ljd.12 for ; Sat, 30 Mar 2019 10:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=beyhB6lVljywyNB9oOMjClZFho1egNhaGdBfwfOVZJk=; b=HNLe0b3zBn5uphaNuZIp8EjWNxsktADrGJGgA77KSX1EPoz0skooeMSSZIQlHLe0dV ybyNYsVeYS6TossBku4xTZWYNWdHjASM1c4dax9TEC2gr/+/UTHWLZ3zdWRp+RxB2Snz ntqaH7zqMHUKT5LIkLIfdtGUDv3cD8sGOG6XE= 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=beyhB6lVljywyNB9oOMjClZFho1egNhaGdBfwfOVZJk=; b=Epje7aJvVaU1jXF10ddp6cfvkd24Kb26r738PoBfGQU/witkNdxkBpMRoI4hksMy88 3LoSqB1Ln49KcEhfFjFoBspeqRbVIciVO94W/ZCU9dh3Bz4SpgGzGfh2D8D179hm8IfM UbEmPAAaTQAjZykIrVz7cWx91iQGehTITRajNQ4+UxkY8GvReJ/WG5BGcj6VwSxIAWin cWx18cuXJnS4N7XtdWK6Go8Un0acHJtTyCzH6mbXAKReq4nUM6oJdFxhwuRP2XIiArIG 3OmyA0ajobPVG+AusV66j9M7S/T+eC39GFGDgXz0VuwCRZXRd+mrdqosT1V2Ezdqhy9R 5QvQ== X-Gm-Message-State: APjAAAVi6EmFlTd0TYzNLncTYS/1AK4SFDS3+58F7OtlUV7gEtC2mYcR lRkOEmrZwAhBu4/iJD5DHJVA2BWmWAs= X-Received: by 2002:a2e:9213:: with SMTP id k19mr8615919ljg.118.1553966677764; Sat, 30 Mar 2019 10:24:37 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com. [209.85.167.49]) by smtp.gmail.com with ESMTPSA id 1sm1024192ljw.56.2019.03.30.10.24.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Mar 2019 10:24:36 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id b7so3498268lfg.9 for ; Sat, 30 Mar 2019 10:24:36 -0700 (PDT) X-Received: by 2002:a19:954b:: with SMTP id x72mr27981956lfd.67.1553966676025; Sat, 30 Mar 2019 10:24:36 -0700 (PDT) MIME-Version: 1.0 References: <20190329155425.26059-1-christian@brauner.io> <20190330171215.3yrfxwodstmgzmxy@brauner.io> In-Reply-To: <20190330171215.3yrfxwodstmgzmxy@brauner.io> From: Linus Torvalds Date: Sat, 30 Mar 2019 10:24:19 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() To: Christian Brauner Cc: Daniel Colascione , 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 , Aleksa Sarai , 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 Sat, Mar 30, 2019 at 10:12 AM Christian Brauner wrote: > > > To clarify, what the Android guys really wanted to be part of the api is > a way to get race-free access to metadata associated with a given pidfd. > And the idea was that *if and only if procfs is mounted* you could do: > > int pidfd = pidfd_open(1234, 0); > > int procfd = open("/proc", O_RDONLY | O_CLOEXEC); > int procpidfd = ioctl(pidfd, PIDFD_TO_PROCFD, procfd); And my claim is that this is three system calls - one of them very hacky - to just do int pidfd = open("/proc/%d", O_PATH); and you're done. It acts as the pidfd _and_ the way to get the associated status files etc. So there is absolutely zero advantage to going through pidfd_open(). No. No. No. So the *only* reason for "pidfd_open()" is if you don't have /proc in the first place. In which case the whole PIDFD_TO_PROCFD is bogus. Yeah, yeah, if you want to avoid going through the pathname translation, that's one thing, but if that's your aim, then you again should also just admit that PIDFD_TO_PROCFD is disgusting and wrong, and you're basically saying "ok, I'm not going to do /proc at all". So I'm ok with the whole "simpler, faster, no-proc pidfd", but then it really has to be *SIMPLER* and *NO PROCFS*. PIDFD_TO_PROCFD violates *everything*. Linus