[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200618091857.atycw6ioaiuhddmj@wittgenstein>
Date: Thu, 18 Jun 2020 11:18:57 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Wolfgang Bumiller <w.bumiller@...xmox.com>,
Serge Hallyn <serge@...lyn.com>,
Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] nsfs: add NS_GET_INIT_PID ioctl
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
> <christian.brauner@...ntu.com> 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
Powered by blists - more mailing lists