Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2486146yba; Mon, 15 Apr 2019 12:40:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqzYdzVx5m78nElH3NY1dJPpfDfb6FyqN1rTwVkt/CMRhTPq6cW5Eapkv4JvmqVJMZaE6n/Q X-Received: by 2002:a63:614c:: with SMTP id v73mr71082861pgb.395.1555357218030; Mon, 15 Apr 2019 12:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555357218; cv=none; d=google.com; s=arc-20160816; b=H702itN6n3RshjN8Ej7FTu2VwLaDbM2a9FwYOubQi7dCPA6aDconbLESYBKNOY+1k+ DFOZuB3U3uekwR4hgAtlpRBJTyh4giXXPOTl7mRPDw3lq3DP2j4juGcERD8bZzjBWIRi SK3T+DQRr9MH6pUQGxulmdzwHOUKR+kc1Yx036KxOBZOne9uTk3XfbljpfNYYui7/8Vo kWxcsxaBgKVkHpZYGyg/+EWYIck00AaHsUhsUf0JvRSeaKc8//FFCr2MLQuFiIu6sOkn 89u+3+KXfpCRtvTSzn5r25n7brq25d7z9zFRYEeC1wFrxmXpn+TSKf0aDpwp/CImOH5r OuMA== 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=CMB1Xiarl5PcZSg9vVu/GRE6BQorb4XVsU8O0cUqVsU=; b=vs0gsBYji/NQSnd1Mn03FNFcAp0z743vVc6A3OPK8u2ATjE1E5uiKsPTyYQT5rhamb ZuHs6qfASLIudqCeiNPpNZJ8VEgEmzcI039xsVhkujdcWdnJo840ZZydypWNRPlH6Je1 OL6SQ65jSL+PGQKD62BZC3LvUzTDS/8D8a1MQeAitRGcfofQ48mqchRFYDcwUn/xFqFI 4rUR4hfR5xnc97DH/GFw/K0H/70rju1ykQOLUIdAri3y8LXZT2ddP5xoIAoy7uJju2D9 RAew7h6UvfQqgqvc5GUBIptK6nHkgsf+sFfbSC9KgEi5y9KctcmAy1RfiCcpkEStTv1j s5GA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=BKLxGDSl; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k72si45526894pgc.362.2019.04.15.12.40.01; Mon, 15 Apr 2019 12:40:18 -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=@google.com header.s=20161025 header.b=BKLxGDSl; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728595AbfDOTjQ (ORCPT + 99 others); Mon, 15 Apr 2019 15:39:16 -0400 Received: from mail-vk1-f195.google.com ([209.85.221.195]:36935 "EHLO mail-vk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728251AbfDOTjO (ORCPT ); Mon, 15 Apr 2019 15:39:14 -0400 Received: by mail-vk1-f195.google.com with SMTP id o187so3912090vkg.4 for ; Mon, 15 Apr 2019 12:39:14 -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=CMB1Xiarl5PcZSg9vVu/GRE6BQorb4XVsU8O0cUqVsU=; b=BKLxGDSl5+TsetRL/bEUshtZAOrv8PcHg3pn8gD/QXNHMWbfZXrRZrAVjR5M3KMyUN ed7fBPkMlMSdDsobZX6+U5/4BBlbC0XUSQp5YC1PzTkBtaQtK+fVP9p38yPLv0hTzU/A cKOlswBu/5wIJy9MaFrRr/xwcNt8TyJeS5GSNBgC1l9oWttuOZ7N4IF/g4/VGkeXSxl+ bnCprrdU2ra8shjwHOuZikXLJkJAtvwc7O4qvjJMFBIxJE7m+vPKjYwPMufXcsJad01S lUjyEtRAD7ivCLIEnGP0beOCRuq1cD+8+pN7lJImhZF5LpEyKeGvEtM6qDSav/QiZpku mkYw== 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=CMB1Xiarl5PcZSg9vVu/GRE6BQorb4XVsU8O0cUqVsU=; b=omJEWItfDOWI3eEzj8DUW8smYaBL2Yb3x7ndqvzFJae9+SUC6D9QIbOuvVXegNrRGv lIt7IprtRh6A93u1kRPJB1PGqErNeuxyai3rweqYtNQBu11x3AsTChr1B1zjeTaPaqj9 WeQsqASrP1G7ODC7rY2TQnmjDaVj+HaI5dMO4VF5IaCyNbOP1byYFWSOntyUUJPmKeEF JpMJ0hiXAYvREnqP2JpzZVULA+/MIFbJwhRxEHJqjvRqnopwpL5Bd+Pl+QOi04w6K8Wt HTuGSM9O1nlI6pS8lvL/HoEsdG2JRtwDjXEcxKMT6PwAhE6RsI0B7AU0YZ71gRJ1UGtA 1lxg== X-Gm-Message-State: APjAAAU0VvuHMvpSnokzzVFeN9TCSWn9LiXeDauXlsCC8++yTg55DimH KXcoxqTMeEUHsrY9QyZC+lW7fXXVC1ig9d5ba3JzYw== X-Received: by 2002:a1f:8c94:: with SMTP id o142mr40823622vkd.61.1555357153147; Mon, 15 Apr 2019 12:39:13 -0700 (PDT) MIME-Version: 1.0 References: <20190414201436.19502-1-christian@brauner.io> <20190414201436.19502-3-christian@brauner.io> <20190415105209.GA22204@redhat.com> <20190415114204.ydczeuwmi74wfsuv@brauner.io> <20190415132416.GB22204@redhat.com> In-Reply-To: From: Daniel Colascione Date: Mon, 15 Apr 2019 12:39:01 -0700 Message-ID: Subject: Re: [PATCH 2/4] clone: add CLONE_PIDFD To: Jonathan Kowalski Cc: Oleg Nesterov , Christian Brauner , Linus Torvalds , Al Viro , Jann Horn , David Howells , Linux API , linux-kernel , "Serge E. Hallyn" , Andy Lutomirski , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Thomas Gleixner , Michael Kerrisk-manpages , Andrew Morton , Aleksa Sarai , 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 15, 2019 at 10:15 AM Jonathan Kowalski wrote: > > Why else do we want pidfd? > > Apart from what others have already pointed out, there are two other > things I am looking forward to: Everything that Christian, Joel, and Jonathan have said is right. If I can wax philosophical for a bit (as I've been accused to doing :-)), there's a lot of value in consistency itself, a "more than the sum of its parts" effect that arises from modeling all kernel-resource handles as file descriptors. You get lifecycle consistency, API consistency (e.g., dup, close), introspection consistency (via /proc/pid/fd and friends), wait consistency, IPC consistency, and tons of other benefits from using a file descriptor. The alternatives tend to be very ugly: one of SysV IPC's* biggest mistakes, for example, was having users manage its resources via non-file-descriptor kernel handles. The process is, I think, the last major class of kernel resource that users can't manipulate via file descriptor. Even if using pidfds didn't provide strong immediate and direct benefits, it'd *still* be worth moving to a file descriptor resource handle model for the sake of making the system interface regular and uniform. * Does anyone know *why* the SysV people didn't use FDs? The consistency argument I'm making was just as relevant then as it is now.