archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <>
To: Al Viro <>
Cc: John Ericson <>,
	LKML <>,
	David Laight <>,
	Andy Lutomirski <>,
	"Jason A. Donenfeld" <>,
	Kernel Hardening <>,
	Jann Horn <>,
	Christian Brauner <>
Subject: Re: Leveraging pidfs for process creation without fork
Date: Mon, 2 Aug 2021 14:19:35 +0200	[thread overview]
Message-ID: <20210802121935.dkiw627twcrxbh54@wittgenstein> (raw)
In-Reply-To: <>

On Sat, Jul 31, 2021 at 10:42:16PM +0000, Al Viro wrote:
> On Sat, Jul 31, 2021 at 03:11:03PM -0700, John Ericson wrote:
> > 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).
> 	It's more on the exit/exec/coredump side, actually.  For
> exit we want to be sure that no new live threads will appear in a
> group once the last live thread has entered do_exit().  For
> exec (de_thread(), for starters) you want to have all threads
> except for the one that does execve() to be killed and your
> thread to take over as group leader.  Look for the machinery there
> and in do_exit()/release_task() involved into that.  For coredump
> you want all threads except for dumper to be brought into do_exit()
> and stopped there, for dumping one to be able to access their state.
> 	Then there's fun with ->sighand treatment - the whole thing
> critically relies upon ->sighand being shared for the entire thread
> group; look at the ->sighand->siglock uses.
> 	The whole area is full of rather subtle places.  Again, the
> real headache comes from the exit and execve.  Embryonic threads are
> passive; it's the ones already running that can (and do) cause PITA.

Iiuc, you're talking about adding a thread into a thread-group tg1 from
a thread in another thread-group tg2. I don't think that's a very
pressing use-case and I agree that that sounds rather nasty right now.
Unless I'm missing something, a simple api to create something like a
processes configuration context doesn't require this.

  reply	other threads:[~2021-08-02 12:19 UTC|newest]

Thread overview: 13+ 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:51 ` Jason A. Donenfeld
2021-02-01 18:20 ` Christian Brauner
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
     [not found]           ` <>
2021-07-31 22:42             ` Al Viro
2021-08-02 12:19               ` Christian Brauner [this message]
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:

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

  git send-email \
    --in-reply-to=20210802121935.dkiw627twcrxbh54@wittgenstein \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).