Re: [PATCH] allow execve'ing "/proc/self/exe" even if /proc is not mounted

From: Mike Frysinger
Date: Thu Jun 25 2009 - 14:17:01 EST


On Thu, Jun 25, 2009 at 14:02, Eric W. Biederman wrote:
> Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx> 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.

this has already been implemented in uClibc with the hints from Jamie
Lokier, but this was done only recently. before that, the only way to
daemonize was to vfork+re-exec.

>> 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.

that isnt really feasible.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/