Linux userland API discussions
 help / color / mirror / Atom feed
From: Christian Brauner <christian@brauner.io>
To: Andy Lutomirski <luto@kernel.org>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
	"Tim Murray" <timmurray@google.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Sultan Alsawaf" <sultan@kerneltoast.com>,
	"Jonathan Kowalski" <bl0pbl33p@gmail.com>,
	"open list:ANDROID DRIVERS" <devel@driverdev.osuosl.org>,
	"Daniel Colascione" <dancol@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	kernel-team <kernel-team@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Jann Horn" <jannh@google.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Martijn Coenen" <maco@android.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Linux API" <linux-api@vger.kernel.org>
Subject: Re: pidfd design
Date: Tue, 26 Mar 2019 01:12:32 +0100	[thread overview]
Message-ID: <20190326001231.3tnhhlvzg26mof33@brauner.io> (raw)
In-Reply-To: <CALCETrXfNV5marXSEDGm6F03DNC2a_M+NE94=GxEbH9oJyWkYA@mail.gmail.com>

On Mon, Mar 25, 2019 at 05:00:17PM -0700, Andy Lutomirski wrote:
> On Mon, Mar 25, 2019 at 4:45 PM Christian Brauner <christian@brauner.io> wrote:
> >
> > On Mon, Mar 25, 2019 at 04:42:14PM -0700, Andy Lutomirski wrote:
> > > On Mon, Mar 25, 2019 at 1:23 PM Daniel Colascione <dancol@google.com> wrote:
> > > >
> > > > On Mon, Mar 25, 2019 at 1:14 PM Jann Horn <jannh@google.com> wrote:
> > > > >
> > > > > On Mon, Mar 25, 2019 at 8:44 PM Andy Lutomirski <luto@kernel.org> wrote:
> > >
> > > > > One ioctl on procfs roots to translate pidfds into that procfs,
> > > > > subject to both the normal lookup permission checks and only working
> > > > > if the pidfd has a translation into the procfs:
> > > > >
> > > > > int proc_root_fd = open("/proc", O_RDONLY);
> > > > > int proc_dir_fd = ioctl(proc_root_fd, PROC_PIDFD_TO_PROCFSFD, pidfd);
> > > > >
> > > > > And one ioctl on procfs directories to translate from PGIDs and PIDs to pidfds:
> > > > >
> > > > > int proc_pgid_fd = open("/proc/self", O_RDONLY);
> > > > > int self_pg_pidfd = ioctl(proc_pgid_fd, PROC_PROCFSFD_TO_PIDFD, 0);
> > > > > int proc_pid_fd = open("/proc/thread-self", O_RDONLY);
> > > > > int self_p_pidfd = ioctl(proc_pid_fd, PROC_PROCFSFD_TO_PIDFD, 0);
> > > > >
> > >
> > > This sounds okay to me.  Or we could make it so that a procfs
> > > directory fd also works as a pidfd, but that seems more likely to be
> > > problematic than just allowing two-way translation like this
> > >
> > > > >
> > > > > And then, as you proposed, the new sys_clone() can just return a
> > > > > pidfd, and you can convert it into a procfs fd yourself if you want.
> > > >
> > > > I think that's the consensus we reached on the other thread. The
> > > > O_DIRECTORY open on /proc/self/fd/mypidfd seems like it'd work well
> > > > enough.
> > >
> > > I must have missed this particular email.
> > >
> > > IMO, if /proc/self/fd/mypidfd allows O_DIRECTORY open to work, then it
> > > really ought to do function just like /proc/self/fd/mypidfd/. and
> > > /proc/self/fd/mypidfd/status should work.  And these latter two
> > > options seem nutty.
> > >
> > > Also, this O_DIRECTORY thing is missing the entire point of the ioctl
> > > interface -- it doesn't require procfs access.
> >
> > The other option was to encode the pid in the callers pid namespace into
> > the pidfd's fdinfo so that you can parse it out and open /proc/<pid>.
> > You'd just need an event on the pidfd to tell you when the process has
> > died. Jonathan and I just discussed this.
> 
> From an application developer's POV, the ioctl interface sounds much,
> much nicer.

Some people are strongly against ioctl()s some don't. I'm not against
them so both options are fine with me if people can agree.

Christian

  reply	other threads:[~2019-03-26  0:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190319231020.tdcttojlbmx57gke@brauner.io>
     [not found] ` <20190320015249.GC129907@google.com>
     [not found]   ` <CAKOZuetJzg_EiyuK7Pa13X3LKuBbreg7zJ5g4uQv_uV4wpmZjg@mail.gmail.com>
     [not found]     ` <20190320035953.mnhax3vd47ya4zzm@brauner.io>
     [not found]       ` <CAKOZuet3-VhmC3oHtEbPPvdiar_k_QXTf0TkgmH9LiwmW-_oNA@mail.gmail.com>
     [not found]         ` <4A06C5BB-9171-4E70-BE31-9574B4083A9F@joelfernandes.org>
     [not found]           ` <20190320182649.spryp5uaeiaxijum@brauner.io>
     [not found]             ` <CAKOZuevHbQtrq+Nb-jw1L7O72BmAzcXmbUnfnseeXZjX4PE4tg@mail.gmail.com>
     [not found]               ` <20190320185156.7bq775vvtsxqlzfn@brauner.io>
     [not found]                 ` <CALCETrXO=V=+qEdLDVPf8eCgLZiB9bOTrUfe0V-U-tUZoeoRDA@mail.gmail.com>
     [not found]                   ` <20190320191412.5ykyast3rgotz3nu@brauner.io>
     [not found]                     ` <CAKOZuesRwQ4=Svu1KgHWY=HZSS8mF8uFmuzuVOSH0QpJoy7a5w@mail.gmail.com>
     [not found]                       ` <CALCETrUFrFKC2YTLH7ViM_7XPYk3LNmNiaz6s8wtWo1pmJQXzg@mail.gmail.com>
2019-03-25 20:13                         ` pidfd design Jann Horn
2019-03-25 20:23                           ` Daniel Colascione
2019-03-25 23:42                             ` Andy Lutomirski
2019-03-25 23:45                               ` Christian Brauner
2019-03-26  0:00                                 ` Andy Lutomirski
2019-03-26  0:12                                   ` Christian Brauner [this message]
2019-03-26  0:24                                     ` Andy Lutomirski
2019-03-28  9:21                                       ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190326001231.3tnhhlvzg26mof33@brauner.io \
    --to=christian@brauner.io \
    --cc=arve@android.com \
    --cc=bl0pbl33p@gmail.com \
    --cc=dancol@google.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=maco@android.com \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sultan@kerneltoast.com \
    --cc=surenb@google.com \
    --cc=timmurray@google.com \
    --cc=tkjos@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox