Re: [musl] musl-libc/MIPS: detached thread exit broken since kernel commit 46e12c07b

[Rich Felker]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/