As stated in previous bug reports   , clone(CLONE_VM) reset the pthread pid/tid to -1 leading to inconsistent internal state.
This has not been an issue since clone itself is a trick syscall when used along with glibc (since glibc requires consistent pthread internal state), however recent posix_spawn shown this issue because it using internally clone(CLONE_VM) in a controlled way (just to spawn the new thread).
In the libc-alpha mailist  discussion was raised the question why exactly clone(CLONE_VM) requires to clear the pthread and it was concluded that in fact it is wrong to mess with parent's thread structure. The proposed solution is, like CLONE_THREAD, avoid to clear the pid/tid fields for CLONE_VM.
This breaks recursive mutexes after a call to posix_spawn.
I have sent a third version with a proposed fix to all architectures . The fixes for alpha, microblaze, sh, ia64, tile, hppa, m68k, and nios2 have not been tested I would appreciate any possible review.
Fixed by 0cb313f7cb0e418b3d56f3a2ac69790522ab825d.
*** Bug 19859 has been marked as a duplicate of this bug. ***
The fix for this bug breaks backward compatibility.
Author: Adhemerval Zanella <email@example.com>
Date: Mon Oct 10 15:08:39 2016 -0300
Remove cached PID/TID in clone
As you noted it was fixed by c579f48 (Remove cached PID/TID in clone) on master by removing the Linux getpid implementation altogether (and then use the auto-generation syscall). I think for 2.24 the straightforward fix is just remove getpid Linux implementation.