Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
From: Stas Sergeev
Date: Thu Aug 13 2015 - 16:10:08 EST
13.08.2015 22:49, Andy Lutomirski ÐÐÑÐÑ:
On Aug 13, 2015 12:05 PM, "Stas Sergeev" <stsp@xxxxxxx> wrote:
Null descriptor and TLS base in MSR I guess, no?
13.08.2015 21:41, Andy Lutomirski ÐÐÑÐÑ:
Ah, you want it restored on signal delivery. What would it be
Stas: I think uc_flags is okay. We don't currently read it during
Andy, we definitely have some communication discontinuity here. :)
sigreturn, but I see no reason that we can't start reading it.
The point is not sigreturn. If we are talking about the flags that
will in the future control also TLS, how would you limit it to sigreturn()?
It should control the restoring of FS _on signal delivery_, not only
on sigreturn()! So how uc_flags can be used for this at all?
ISTM that can be done easily enough in user code, so
But it is actually not.
maybe we should leave it to user code.
gcc relies of fs pointing to TLS on the function prolog, so
the asm signal handlers again?
And there are just too many trickery for an asm handler.
Should it do the syscall to set fs base via MSR? And to what
value? Why do you think the user should mess with all this
pain? It is just much easier to do on a kernel side, is it not?
And IMHO this is the kernel's responsibility to adhere to the
ABI constraints when entering the signal handler, and the
ABI says fs should point to TLS.
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/