Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1175511ybt; Thu, 18 Jun 2020 02:21:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEHPNj9tReDoj33wQ03BdILY//BjnEzMjlF1C/eILBMraBqBCrqAfBqzOVqaku6ENiCZ7i X-Received: by 2002:aa7:d6d0:: with SMTP id x16mr3223929edr.175.1592472099890; Thu, 18 Jun 2020 02:21:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592472099; cv=none; d=google.com; s=arc-20160816; b=dZ6KA+5DP64OSVQ17j6JRb47uL+T1yhQP1JSLqFZM25VeDVPLh6J4YQghgFOyF200h SNEAQhntbLyTeM6xCBqbYbgeY22EG1vB5e/AbW8k3w5MecxwuFQciSv2QjViHMA0lzFf AktIzdqBcR57zyIHrQkg3cK9g/GVCyE9BqZ2UxHdL6rLPWSYHC4BJ1/6DqgDvKiB5mCE rOy+Y1ftIyNv9NawzE8Y8B1fu8LTWEEBYV3MkmNMZJ4N5a/THhxByjrRkZV7c0j7TdTT Mlb+JKkibRXKAyEAOo9bIlRNmEQJGWKkkEyMNvVqEFQFciCKl/7svV94s6E4LYf1q6Uw j+sA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=dm9WBiiasuSPwhXOJ6lqaDwTH/j6BSK31vetlxmLC/8=; b=MNH1mccT6ckhI5vpLGRPwOsGwjveVNjtKKRcGKSOvX7LXGfErPhsBebN/OfKrUQ/v7 ceLNUz6xQFdV02BUc/TscGloixUN/ckcGf0x7fciJMBg+IP1DA6zd9Bp7WUhkwYIHs9q wlN1+i/b1Co3PozkguAgsjWPDyUDsXHBS43m82VsTCD2pL5+OtUGWktFF5ZhwXe5npj6 mpEX9Yxh54f8xeXCQZmDk2aCpiokEhb6kTeS+AVOCy97BUkS7ENXbtCdLDNd9xlbrXfs +iNHulgVOH9a827x+sMkxbwsIh9+oCFE124+FyxOTRZiqcc3axD6a/QeTQM64HbA/jly ehNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v10si1546383eda.476.2020.06.18.02.21.17; Thu, 18 Jun 2020 02:21:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729066AbgFRJTH (ORCPT + 99 others); Thu, 18 Jun 2020 05:19:07 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:45731 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728343AbgFRJTG (ORCPT ); Thu, 18 Jun 2020 05:19:06 -0400 Received: from ip-109-41-0-102.web.vodafone.de ([109.41.0.102] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jlqhL-00060Q-8F; Thu, 18 Jun 2020 09:19:04 +0000 Date: Thu, 18 Jun 2020 11:18:57 +0200 From: Christian Brauner To: "Michael Kerrisk (man-pages)" Cc: "linux-fsdevel@vger.kernel.org" , lkml , Wolfgang Bumiller , Serge Hallyn , Alexander Viro Subject: Re: [PATCH] nsfs: add NS_GET_INIT_PID ioctl Message-ID: <20200618091857.atycw6ioaiuhddmj@wittgenstein> References: <20200618084543.326605-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 18, 2020 at 11:03:25AM +0200, Michael Kerrisk (man-pages) wrote: > On Thu, 18 Jun 2020 at 10:45, Christian Brauner > wrote: > > > > Add an ioctl() to return the PID of the init process/child reaper of a pid > > namespace as seen in the caller's pid namespace. > > What are the pros and cons of returning a PID FD instead of a PID? A pidfd doesn't buy you much here since you can race-free turn the PID into a pidfd via pidfd_open() right after. But mostly, I don't want to introduce the pattern of returning pidfds from all corners of the kernel especially when it's not strictly required. The central entrypoints should remain clone{3}() and pidfd_open() for now. I want to remain conservative with this until we have had more of userspace rely on them for a while and the bugs and features requests come trickling in. We've seen a good portion of that but we'll likely see more. If we need to do global changes (e.g. sending signals outside of your own pid namespace hierarchy or attaching capabilities to them) we will be in better shape if we don't return them from everywhere just yet. Christian