Hi Al, Andrew, folks,
This is a version 2 of re-execution patch.
I replaced hardcoded "/proc/self/exe" with execve(NULL)
extension in the hopes that this is considered less ugly.
Also I tried to format code according to Andrew's wishes.
Handling execve(NULL) requires adding a bit of code
to per-architecture sys_execve().
In the attached patch, it is done only on x86.
If this patch will be ACKed in principle,
the final version will do it for all architectures.
Description follows.
=========================================================
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".
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.
More elegant way is to execute /proc/self/exe.
This works just fine as long as /proc is mounted.
But it breaks if /proc isn't mounted, and this can happen in real-world
usage. For example, when shell invoked very early in initrd/initramfs.
Or when the program is in a chroot jail. Etc.
With this patch, it is possible to re-execute current binary
even if /proc is not mounted. It is done with execve()
call with NULL pointer as a 1st parameter instead of filename to exec.
Please comment.
Signed-off-by: Denys Vlasenko <[email protected]>
--
vda
On Tue, 30 Jun 2009 00:03:39 +0200
Denys Vlasenko <[email protected]> wrote:
> Hi Al, Andrew, folks,
>
> This is a version 2 of re-execution patch.
>
> I replaced hardcoded "/proc/self/exe" with execve(NULL)
So you add hacks to sys_execve, which means hacks on every system that
doesn't need it and also undefined behaviour if you use the feature when
it isn't present.
This makes no sense.
> extension in the hopes that this is considered less ugly.
> Also I tried to format code according to Andrew's wishes.
>
> Handling execve(NULL) requires adding a bit of code
> to per-architecture sys_execve().
Please implement sys_reexec() as was suggested before. Not only does it
allow this stuff to stay out of the exec() call without risking mashing
up the API and changing ABI in odd corner cases it means its actually
going to be usable by apps - because a reexec() is going to give you a
-ENOSYS on older platforms not randomness.
> In the attached patch, it is done only on x86.
> If this patch will be ACKed in principle,
> the final version will do it for all architectures.
NAK in principle.
Alan
On Tue, Jun 30, 2009 at 12:27 AM, Alan Cox<[email protected]> wrote:
> On Tue, 30 Jun 2009 00:03:39 +0200
> Denys Vlasenko <[email protected]> wrote:
>
>> Hi Al, Andrew, folks,
>>
>> This is a version 2 of re-execution patch.
>>
>> I replaced hardcoded "/proc/self/exe" with execve(NULL)
>
> So you add hacks to sys_execve, which means hacks on every system that
> doesn't need it
Yes.
> and also undefined behaviour if you use the feature when
> it isn't present.
The behavior of execve(NULL) is not undefined. It returns EFAULT.
The idea was that application will do:
/* Try traditional way */
execv("/proc/self/exe", argv);
/* Try Linux specific extension (only new kernels have it) */
execv(NULL, argv);
/* Give up */
printf("Can't re-exec myself\n");
exit(1);
which is safe on older kernels as well.
> Please implement sys_reexec() as was suggested before.
Ok.
--
vda
> The behavior of execve(NULL) is not undefined. It returns EFAULT.
> The idea was that application will do:
That depends what you have mapped at address zero and if your platform
supports EFAULT reporting for address zero. It isn't a reliable
assumption.
Alan