Re: execve is not atomic, what is the exit state of the process when execve fails after throwing away the original process image?

["Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[CC+=Rich Felker, because the discussion started with a reference to
http://ewontfix.com/14/ ]

On 05/04/2014 12:18 AM, Steven Stewart-Gallus wrote:
> 
> ----- Original Message -----
> From: Jann Horn <jann-XZ1E9jl8jIdeoWH0uzbU5w@public.gmane.org>
> Date: Saturday, May 3, 2014 10:45 am
> Subject: Re: execve is not atomic, what is the exit state of the process when
> execve fails after throwing away the original process image?
> To: Steven Stewart-Gallus <sstewartgallus00-QKvm5KDIoDa7M0a00MdBSQ@public.gmane.org>
> Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 
>> On Fri, May 02, 2014 at 02:19:52AM +0000, Steven Stewart-Gallus wrote:
>>> execve is not atomic, what is the exit state of the process when
>>> execve fails after throwing away the original process image?
>>
>> See http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L740 or
>> so – as far as I know, the kernel sends a SIGKILL. Does that help?
>
> Thank you Jann
> Horn. http://lxr.free-electrons.com/source/fs/binfmt_elf.c#L740
> answers my question.
> 
> On reflection, the kernel code makes sense. The process must either
> exit with an error code or raise the SIGKILL signal because SIGKILL
> and SIGSTOP are the only unblockable signals (of course, the kernel
> has the privileges to do whatever it wants but it tries to be
> consistent with userspace).
> 
> Strangely, in other places the SIGSEGV is sent when the ELF file is
> incorrect in some places and I don't fully understand that part of the
> code. Still, I understand enough to look at the code in more detail
> later.
> 
> Thank you,
> Steven Stewart-Gallus
> 
> P.S.
> 
> I'm CC'ing Michael because he wanted to know this case so could
> document it.

Fair enough. I plan to add the following text to the execve(2) man
page:

       In most cases where execve()  fails,  control  returns  to  the
       original  executable image, and the caller of execve() can then
       handle the error.  However, in (rare) cases  (typically  caused
       by resource exhaustion), failure may occur past the point of no
       return: the original exectable image has been  torn  down,  but
       the  new  image  could not be completely built.  In such cases,
       the kernel kills the process with a SIGKILL signal.

Comments?

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html