posix_spawn(): errno in older glibc versions
Florian Weimer
fweimer@redhat.com
Mon Mar 4 07:57:00 GMT 2019
* Felipe Gasper:
> INQUIRY #1:
> I’m curious what allows the newer posix_spawn() to report the
> exec()’s errno in this case. From my reading of vfork(2)’s man
> page (“Standard Description”), any behavior that would indicate
> the exec’s errno back to the parent process seems to be
> undefined behavior:
>
> -----
> the behavior is undefined if the process created by vfork()
> either modifies any data other than a variable of type pid_t used to
> store the return value from vfork(), or returns from the function in
> which vfork() was called, or calls any other function before success-
> fully calling _exit(2) or one of the exec(3) family of functions.
> -----
>
> How, then, does the new posix_spawn() pass the child’s errno back to
> the parent? Does it violate the above--assumedly with some assurance
> that what it’s doing is, in fact, safe?
We know how the Linux kernel behaves. There are some heuristic
emulations that self-identify as Linux (but are not, not really) and
which treat vfork as fork.
Alternatively, it would be possible to use a close-on-exec pipe
descriptor to return the error.
> INQUIRY #2:
> Putting questions of distribution aside, how feasible would it
> be to patch the older glibc versions (2.12 and 2.17) to report
> the child’s errno to the parent?
Technically, it's not too hard, but you would have to avoid introducing
the GLIBC_2.15 symbol version for the backport to 2.12.
It may be easier to switch the pipe trick instead of using the upstream
code. glibc-2.12-based systems in particular tend to have kernels which
also had vfork issues (particularly with ptrace).
Thanks,
Florian
More information about the Libc-help
mailing list