All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John Ericson" <mail@johnericson.me>
To: "Al Viro" <viro@zeniv.linux.org.uk>,
	"Christian Brauner" <christian.brauner@ubuntu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	"David Laight" <David.Laight@aculab.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
	"Jann Horn" <jann@thejh.net>,
	"Christian Brauner" <christian.brauner@canonical.com>
Subject: Re: Leveraging pidfs for process creation without fork
Date: Sat, 31 Jul 2021 15:11:03 -0700	[thread overview]
Message-ID: <1468d75c-57ae-42aa-85ce-2bee8d403763@www.fastmail.com> (raw)
In-Reply-To: <YQNYs+BKenJHBMSP@zeniv-ca.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]

Do you mind pointing out one of those examples? I'm new to this, but if they follow a pattern I should be able to find the other examples based off it. I'm certainly curious to take a look :).

I hope these issues aren't to deep. Ideally there's a nice decoupling so the creating process is just manipulating "inert" data structures for the embryo that scheduler doesn't even need see, and then after the embryonic process is submitted, when the context switches to it for the first time that's a completely normal process without special cases.

The place complexity is hardest to avoid I think would be cleaning up the yet-unborn embryonic processes orphaned by exitted parent(s), because that will have to handle all the semi-initialized states those could be in (as opposed to real processes).

John

On Thu, Jul 29, 2021, at 6:41 PM, Al Viro wrote:
> On Thu, Jul 29, 2021 at 04:24:15PM +0200, Christian Brauner wrote:
> > On Wed, Jul 28, 2021 at 12:37:57PM -0400, John Cotton Ericson wrote:
> > > Hi,
> > > 
> > > I was excited to learn about about pidfds the other day, precisely in hopes
> > > that it would open the door to such a "sane process creation API". I
> > > searched the LKML, found this thread, and now hope to rekindle the
> > > discussion; my apologies if there has been more discussion since that I
> > 
> > Yeah, I haven't forgotten this discussion. A proposal is on my todo list
> > for this year. So far I've scheduled some time to work on this in the
> > fall.
> 
> Keep in mind that quite a few places in kernel/exit.c very much rely upon the
> lack of anything outside of thread group adding threads into it.  Same for
> fs/exec.c.
> 

[-- Attachment #2: Type: text/html, Size: 2363 bytes --]

  reply	other threads:[~2021-07-31 22:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 17:47 forkat(int pidfd), execveat(int pidfd), other awful things? Jason A. Donenfeld
2021-02-01 17:47 ` Jason A. Donenfeld
2021-02-01 17:51 ` Jason A. Donenfeld
2021-02-01 17:51   ` Jason A. Donenfeld
2021-02-01 18:20 ` Christian Brauner
2021-02-01 18:29 ` Andy Lutomirski
2021-02-01 18:29   ` Andy Lutomirski
2021-02-02  9:23   ` David Laight
2021-07-28 16:37     ` Leveraging pidfs for process creation without fork John Cotton Ericson
2021-07-29 14:24       ` Christian Brauner
2021-07-29 14:54         ` John Ericson
2021-07-30  1:41         ` Al Viro
2021-07-31 22:11           ` John Ericson [this message]
2021-07-31 22:42             ` Al Viro
2021-08-02 12:19               ` Christian Brauner
2021-08-03  6:00                 ` John Cotton Ericson
2021-02-01 18:32 ` forkat(int pidfd), execveat(int pidfd), other awful things? Casey Schaufler

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=1468d75c-57ae-42aa-85ce-2bee8d403763@www.fastmail.com \
    --to=mail@johnericson.me \
    --cc=David.Laight@aculab.com \
    --cc=Jason@zx2c4.com \
    --cc=christian.brauner@canonical.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=jann@thejh.net \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.