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