Re: RFC: clone with CLONE_VM behavior

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 13-04-2016 10:26, Adhemerval Zanella wrote:
> Hi all,
> 
> Szabolcs has brought to my attention that the new posix_spawn is showing
> some issue on his aarch64 [1], but it is not limited to aarch64.
> 
> The problem is due the fact GLIBC clone implementation resets both
> THREAD_SELF pid and tid when CLONE_VM is specified. This leads to
> inconsistency since the value is not restored back in parent and
> thus INVALID_TD_P and INVALID_NOT_TERMINATED_TD_P (used in pthread
> implementations) will bail with an error handler.
> 
> Previous posix_spawn uses vfork which only interferes with THREAD_SELF
> pid field by negating it before the syscall and restoring the value
> after it.
> 
> I am trying to came up with the best solution for this, since both
> pid and tid is used in both pthread_{join,cancel} and also on raise
> (which also have another issue somewhat related [2]) and I am inclined
> to just remove the CLONE_VM changes to pid/tid fields in the syscall
> itself and moving it to START_THREAD_DEFN instead.

In fact, pthread does not really require it, since it will use CLONE_THREAD
and the glibc clone implementation won't change THERAD_SELF pid/tid field.
So the question is if glibc really should change pid/tid value for
CLONE_VM flag.

My impression is to allow programs that might use this flag to be able
to use the raise function and force pthread call to fail (due invalid
handle), however I am not convinced it is the right path to take
(and with proposed solution on BZ#15368 I think using cached value is
not an option).

> 
> Any better ideas, tips, advices?
> 
> [1] https://sourceware.org/ml/libc-alpha/2016-04/msg00274.html
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=15368
>