All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Frysinger <vapier@gentoo.org>
Subject: Re: [PATCH] allow execve'ing "/proc/self/exe" even if /proc is not  mounted
Date: Thu, 25 Jun 2009 11:02:14 -0700	[thread overview]
Message-ID: <m17hz0i449.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1158166a0906241600w5f7f4ffcm49d9c849f0c27f72@mail.gmail.com> (Denys Vlasenko's message of "Thu\, 25 Jun 2009 01\:00\:56 +0200")

Denys Vlasenko <vda.linux@googlemail.com> writes:

> In some circumstances running process needs to re-execute
> its image.
>
> Among other useful cases, it is _crucial_ for NOMMU arches.
>
> They need it to perform daemonization. Classic sequence
> of "fork, parent dies, child continues" can't be used
> due to lack of fork on NOMMU, and instead we have to do
> "vfork, child re-exec itself (with a flag to not daemonize)
> and therefore unblocks parent, parent dies".

Why?

I would expect a simple assembly wrapper around clone would work.
I.e.  Create a new process but share the MM and reuse the same
stack. When clone returns if we are the parent exit, otherwise
continue on with life.

> Another crucial use case on NOMMU is POSIX shell support.
> Imagine a shell command of the form "func1 | func2 | func3".
> This can be implemented on NOMMU by vforking thrice,
> re-executing the shell in every child in the form
> "<shell> -c 'body of funcN'", and letting parent wait and collect
> exitcodes and such. As far as I can see, it's the only way
> to implement it correctly on NOMMU.
>
> The program may re-execute itself by name if it knows the name,
> but we generally may be unsure about it. Binary may be renamed,
> or even deleted while it is being run.

It really sounds like you want to implement fork for NOMMU.
If you have a base address register which everything is relative
to I can't imagine it would be too hard.  Heck you might even be
able to do it in user space.  

Eric


  parent reply	other threads:[~2009-06-25 18:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-24 23:00 [PATCH] allow execve'ing "/proc/self/exe" even if /proc is not mounted Denys Vlasenko
2009-06-24 23:21 ` Andrew Morton
2009-06-24 23:49   ` Denys Vlasenko
2009-06-24 14:51     ` Pavel Machek
2009-06-25  0:26     ` Andrew Morton
2009-06-26  8:06     ` Florian Weimer
2009-06-24 23:58 ` Al Viro
2009-06-25  0:07   ` Mike Frysinger
2009-06-26 23:18   ` Denys Vlasenko
2009-06-25  8:10 ` Alan Cox
2009-06-26  8:00   ` Denys Vlasenko
2009-06-26 13:26     ` Mike Frysinger
2009-06-26 22:55       ` Denys Vlasenko
2009-06-28 19:31         ` Mike Frysinger
2009-06-25 18:02 ` Eric W. Biederman [this message]
2009-06-25 18:16   ` Mike Frysinger

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=m17hz0i449.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vapier@gentoo.org \
    --cc=vda.linux@googlemail.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 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.