On Mon, Jun 16, 2025 at 11:39:31PM +0200, Florian Weimer wrote:
* Sasha Levin:+ KAPI_RETURN("long", "Does not return on success; returns -1 on error") + .type = KAPI_TYPE_INT, + .check_type = KAPI_RETURN_ERROR_CHECK, + KAPI_RETURN_ENDIs the -1 part correct?
Maybe :) That's one of the things I wasn't sure about: we're documenting the execve syscall rather than the function itself. A user calling execve() will end up with -1 on failure, and errno set with the error code. You could argue that it's libc that sets errno and we're trying to spec the kernel here, not the userspace interface to it. At the end I managed to lawyer myself into a decision that I liked: I figured that since klibc is really a kernel library that is merely packaged seperately from the kernel, it is really a kernel interface, and so I followed the libc convention. Open for suggestions...
Many later errors during execve are not recoverable and result in execve succeeding (nominally) and a fatal signal being delivered to the process instead. Not sure if the description covers that.
I was afraid of the "signals" rabit hole: from what I recall, you can have fatal signals pending past the point of no return but before execve() completes from both execve() failures as well as external sources. There's definitely room for a longer explanation of how all of this works together. I'd suggest that we tackle signal specs in the near future, and see how we can tie those into the rest of the API specs. Right now I'm pretty unhappy with the vague KAPI_SIGNAL().
What about the effect of unblocking a parent thread that has vfork'ed?
In my mind it's vfork() that is waiting for the execve to complete (via wait_for_vfork_done()) rather than execve() actively waking up the vfork() parent. We can list it as a side effect of execve()? I suppose that its similar to something like read() in one process waking up a different process from epoll_wait(), so we should probably be documenting those as well... Thanks for the comments! -- Thanks, Sasha
