On Fri, Jun 19, 2015 at 04:07:52AM +0200, Matthias Schiffer wrote: > Hi, > I've come across the issue that applications with detached threads > (using pthread_detach or a pthread_attr_t with > pthread_attr_setdetachstate) will segfault using musl-libc on MIPS as > soon as the detached thread exits. As far as I can tell, the underlying > issue is the following: > > To clean up after itself, the finishing thread will call __unmapself, > which will unmap the thread's own stack and call the exit syscall > directly after that, without accessing the now unmapped stack. > > This worked fine in 2012, when pthread support for MIPS was implemented > in musl. It seems to have been broken by kernel commit 46e12c07b "MIPS: > O32 / 32-bit: Always copy 4 stack arguments." (also in 2012) which made > the kernel unconditionally copy 4 stack arguments, even when the syscall > doesn't even use the arguments. > > I guess this would be reasonably easy to fix up in musl, but let's also > get the linux-mips people's opinions, as that commit obviously broke the > kernel ABI...
This is kernel ABI breakage that should be fixed -- people running old kernel versions with old musl binaries might suffer a regression when upgrading, and perhaps more importantly the failure mode is just really bad. But I think we can also work around it on the userspace side in musl by pointing the stack pointer at some rodata (or even at pc, e.g. copying $25 to $sp) before making the syscall. Rich -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
