[Bug nptl/10311] clone(CLONE_VM) fails with pthread_getattr_np on i386

bugdal at aerifal dot cx sourceware-bugzilla@sourceware.org
Mon Sep 10 19:10:00 GMT 2018


https://sourceware.org/bugzilla/show_bug.cgi?id=10311

--- Comment #11 from Rich Felker <bugdal at aerifal dot cx> ---
As far as I can tell, clone() is safe to use without CLONE_VM. This limitation
should probably be documented. With CLONE_VM, it's not clear to me what should
happen. As noted before, there are strong reasons it won't work and is unsafe.
There might be ways it could be made safe to use (or conditions under which
it's already safe to use) if you also use CLONE_VFORK or arrange for the same
sort of wait operation to take place in some other way.

It's plausible that CLONE_VM with the public clone() function should
automatically create a valid TCB in the provided stack area (it doesn't do this
now, but perhaps could be modified to do so), but I'm not sure at what point it
would make sense to stop. Would it also need to reserve sufficient storage for
TLS? Only for TLS that existed at the time of the clone call, or for dynamic
TLS added later too? Would it be expected that the child be restricted to an
async signal context, or could it interact with libc locks (malloc?) in the
parent?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Glibc-bugs mailing list