Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1205516 > unrolled thread
| Started by | Stas Sergeev <stsp@list.ru> |
|---|---|
| First post | 2015-08-12 02:20 +0200 |
| Last post | 2015-08-13 22:10 +0200 |
| Articles | 20 on this page of 105 — 8 participants |
Back to article view | Back to linux.kernel
[regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 02:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 02:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 10:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 21:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 21:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 22:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 23:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-12 23:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 00:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Ingo Molnar <mingo@kernel.org> - 2015-08-13 10:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 12:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 14:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 17:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 19:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 19:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 13:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-12 22:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 17:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 18:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Brian Gerst <brgerst@gmail.com> - 2015-08-13 19:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 00:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 11:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 17:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 18:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 00:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-19 12:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-19 17:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 10:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 20:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 20:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 20:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 21:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 22:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-13 23:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 23:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 01:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 01:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Raymond Jennings <shentino@gmail.com> - 2015-08-14 01:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 00:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 00:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 00:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 01:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 01:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 02:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 03:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 03:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 03:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 04:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 03:40 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-14 02:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-14 02:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-14 02:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 09:30 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Pavel Emelyanov <xemul@parallels.com> - 2015-08-14 12:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Cyrill Gorcunov <gorcunov@gmail.com> - 2015-08-14 13:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:00 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Andy Lutomirski <luto@amacapital.net> - 2015-08-13 21:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 21:20 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 21:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Linus Torvalds <torvalds@linux-foundation.org> - 2015-08-13 22:10 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-18 08:50 +0200
Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu Stas Sergeev <stsp@list.ru> - 2015-08-13 22:10 +0200
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 21:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX631-3Qo-43@gated-at.bofh.it> |
| In reply to | #1207064 |
13.08.2015 21:41, Andy Lutomirski пишет: > Stas: I think uc_flags is okay. We don't currently read it during > sigreturn, but I see no reason that we can't start reading it. Andy, we definitely have some communication discontinuity here. :) 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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-13 21:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX6FH-4Hv-3@gated-at.bofh.it> |
| In reply to | #1207078 |
On Aug 13, 2015 12:05 PM, "Stas Sergeev" <stsp@list.ru> wrote: > > 13.08.2015 21:41, Andy Lutomirski пишет: > >> Stas: I think uc_flags is okay. We don't currently read it during >> sigreturn, but I see no reason that we can't start reading it. > > Andy, we definitely have some communication discontinuity here. :) > 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? Ah, you want it restored on signal delivery. What would it be restored to? ISTM that can be done easily enough in user code, so maybe we should leave it to user code. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-13 22:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX78K-5uz-15@gated-at.bofh.it> |
| In reply to | #1207130 |
13.08.2015 22:49, Andy Lutomirski пишет: > On Aug 13, 2015 12:05 PM, "Stas Sergeev" <stsp@list.ru> wrote: >> 13.08.2015 21:41, Andy Lutomirski пишет: >> >>> Stas: I think uc_flags is okay. We don't currently read it during >>> sigreturn, but I see no reason that we can't start reading it. >> Andy, we definitely have some communication discontinuity here. :) >> 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? > Ah, you want it restored on signal delivery. What would it be > restored to? Null descriptor and TLS base in MSR I guess, no? > ISTM that can be done easily enough in user code, so > maybe we should leave it to user code. But it is actually not. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-13 22:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX6Po-4SL-15@gated-at.bofh.it> |
| In reply to | #1207064 |
On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Ok. So I'm inclined to do the bigger revert, just to fix the compile
>> issue. It would be crazy to force some silly autoconf script for
>> random header info.
>
> Yeah, probably makes sense, but one of us should explicitly test CRIU
> (both new and old versions) on the result. CRIU does interesting
> things involving sigcontext and protocol buffers.
I've reverted it in the -git tree, I'm adding Pavel and Cyrill to the
cc, to see if they can check the impact on CRIU..
Pavel/Cyrill? Current top-of-tree (but that will change) commit
ed596cde9425 ("Revert x86 sigcontext cleanups").
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Cyrill Gorcunov <gorcunov@gmail.com> |
|---|---|
| Date | 2015-08-13 22:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX6Z4-5jk-1@gated-at.bofh.it> |
| In reply to | #1207139 |
On Thu, Aug 13, 2015 at 12:53:03PM -0700, Linus Torvalds wrote:
> On Thu, Aug 13, 2015 at 11:41 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> > On Thu, Aug 13, 2015 at 11:35 AM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> >>
> >> Ok. So I'm inclined to do the bigger revert, just to fix the compile
> >> issue. It would be crazy to force some silly autoconf script for
> >> random header info.
> >
> > Yeah, probably makes sense, but one of us should explicitly test CRIU
> > (both new and old versions) on the result. CRIU does interesting
> > things involving sigcontext and protocol buffers.
>
> I've reverted it in the -git tree, I'm adding Pavel and Cyrill to the
> cc, to see if they can check the impact on CRIU..
>
> Pavel/Cyrill? Current top-of-tree (but that will change) commit
> ed596cde9425 ("Revert x86 sigcontext cleanups").
If only I'm not missin something obvious this should not hurt us.
But I gonna build test kernel and check to be sure tomorrow, ok?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-13 22:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX6Z4-5jk-5@gated-at.bofh.it> |
| In reply to | #1207141 |
On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> If only I'm not missin something obvious this should not hurt us.
> But I gonna build test kernel and check to be sure tomorrow, ok?
Thanks,
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Raymond Jennings <shentino@gmail.com> |
|---|---|
| Date | 2015-08-13 23:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX8xP-7ln-7@gated-at.bofh.it> |
| In reply to | #1207142 |
On 08/13/15 13:09, Linus Torvalds wrote: > On Thu, Aug 13, 2015 at 1:08 PM, Cyrill Gorcunov <gorcunov@gmail.com> wrote: >> If only I'm not missin something obvious this should not hurt us. >> But I gonna build test kernel and check to be sure tomorrow, ok? > Thanks, > > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I am curious about what's supposed to happen normally on signal delivery. Is SS a register that's supposed to be preserved like EIP/RIP and CS when a signal is delivered? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-13 23:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX8xP-7ln-19@gated-at.bofh.it> |
| In reply to | #1207190 |
On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com> wrote:
>
> I am curious about what's supposed to happen normally on signal delivery.
>
> Is SS a register that's supposed to be preserved like EIP/RIP and CS when a
> signal is delivered?
What exactly does "supposed" mean?
On x86-64, we traditionally haven't touched SS, because it doesn't
really matter in 64-bit long mode. And apparently dosemu depended on
that behavior.
So clearly, we're not "supposed" to save/restore it. Because reality
matters a hell of a lot more than any theoretical arguments.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Raymond Jennings <shentino@gmail.com> |
|---|---|
| Date | 2015-08-14 00:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX8Rc-7Xe-1@gated-at.bofh.it> |
| In reply to | #1207198 |
On 08/13/15 14:46, Linus Torvalds wrote: > On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com> wrote: >> I am curious about what's supposed to happen normally on signal delivery. >> >> Is SS a register that's supposed to be preserved like EIP/RIP and CS when a >> signal is delivered? > What exactly does "supposed" mean? Basically, when a process/thread receives a signal, what happens to its registers? > So clearly, we're not "supposed" to save/restore it. Because reality > matters a hell of a lot more than any theoretical arguments. So it still counts as a regression if the kernel pulls the rug out from under someone that was relying on undocumented or buggy behavior? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 00:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX8Rc-7Xe-3@gated-at.bofh.it> |
| In reply to | #1207201 |
14.08.2015 01:01, Raymond Jennings пишет: > > > On 08/13/15 14:46, Linus Torvalds wrote: >> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings >> <shentino@gmail.com> wrote: >>> I am curious about what's supposed to happen normally on signal >>> delivery. >>> >>> Is SS a register that's supposed to be preserved like EIP/RIP and CS >>> when a >>> signal is delivered? >> What exactly does "supposed" mean? > Basically, when a process/thread receives a signal, what happens to > its registers? >> So clearly, we're not "supposed" to save/restore it. Because reality >> matters a hell of a lot more than any theoretical arguments. > So it still counts as a regression if the kernel pulls the rug out > from under someone that was relying on undocumented or buggy behavior? > You probably want to read the whole thread... Or start from here: https://lkml.org/lkml/2015/8/12/800 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-14 01:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9Nf-QH-15@gated-at.bofh.it> |
| In reply to | #1207201 |
On Thu, Aug 13, 2015 at 3:01 PM, Raymond Jennings <shentino@gmail.com> wrote:
>
> So it still counts as a regression if the kernel pulls the rug out from
> under someone that was relying on undocumented or buggy behavior?
Absolutely. There are no excuses for regressions. If the code was
badly written and left itself open to user space "misusing" it, it's
our problem. Especially if the code was badly written to begin with,
and user space worked around our bad code.
We don't then "fix" code and blame user space for doing bad things.
In particular, we don't cop out and say "hey, you didn't follow the
docs" (whether they existed or not) or "you didn't do what we meant
you to do".
The _only_ thing that matters is that something broke.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-14 01:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9WW-11U-13@gated-at.bofh.it> |
| In reply to | #1207227 |
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> The _only_ thing that matters is that something broke.
To clarify: things like test programs etc don't matter. Real
applications, used by real users. That's what regressions cover. If
you have a workflow that isn't just some random kernel test thing, and
you depend on it, and we break it, the kernel is supposed to fix it.
There are some (very few) exceptions.
If it's a security issue, we may not be able to "fix" it, because
other concerns can obviously take precedence.
Also, sometimes the reports come in way too late - if you were running
some stable distro kernel for several years, and updated, and notice a
change that happened four years ago and modern applications now rely
on the _new_ behavior, we may not be able to fix the regression any
more.
But no, "it was an unintentional kernel bug and clearly just stupid
crap code, and we fixed it and now the kernel is much better and
cleaner" is not a valid reason for regressions. We'll go back to the
stupid and crap code if necessary, however much that may annoy us.
For an example of the kind of things we may have to do, see commits
64f371bc3107 autofs: make the autofsv5 packet file descriptor use
a packetized pipe
9883035ae7ed pipes: add a "packetized pipe" mode for writing
and just wonder at the insanity. That's the kinds of things that
happen when one application had actively worked around a bug in
compatibility handling, and then trying to "fix" that bug just caused
another application to break instead.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Raymond Jennings <shentino@gmail.com> |
|---|---|
| Date | 2015-08-14 01:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXagi-1os-17@gated-at.bofh.it> |
| In reply to | #1207234 |
On 08/13/15 16:18, Linus Torvalds wrote: > On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> The _only_ thing that matters is that something broke. > To clarify: things like test programs etc don't matter. Real > applications, used by real users. That's what regressions cover. If > you have a workflow that isn't just some random kernel test thing, and > you depend on it, and we break it, the kernel is supposed to fix it. > > There are some (very few) exceptions. > > If it's a security issue, we may not be able to "fix" it, because > other concerns can obviously take precedence. > > Also, sometimes the reports come in way too late - if you were running > some stable distro kernel for several years, and updated, and notice a > change that happened four years ago and modern applications now rely > on the _new_ behavior, we may not be able to fix the regression any > more. > > But no, "it was an unintentional kernel bug and clearly just stupid > crap code, and we fixed it and now the kernel is much better and > cleaner" is not a valid reason for regressions. We'll go back to the > stupid and crap code if necessary, however much that may annoy us. > > For an example of the kind of things we may have to do, see commits > > 64f371bc3107 autofs: make the autofsv5 packet file descriptor use > a packetized pipe > 9883035ae7ed pipes: add a "packetized pipe" mode for writing > > and just wonder at the insanity. That's the kinds of things that > happen when one application had actively worked around a bug in > compatibility handling, and then trying to "fix" that bug just caused > another application to break instead. > > Linus Is there a way to temporally confine the bad crap code just to the applications that depend on it, or does a userspace app latching onto bad behavior effectively lock down the abi for the future? I know that some features in the kernel get deprecated over a process (devfs for example) once userspace is given an alternative...would there be a process like that to deal with userspace code that is pinning a piece of crap in the kernel? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 01:50 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXapX-1zR-5@gated-at.bofh.it> |
| In reply to | #1207234 |
14.08.2015 02:18, Linus Torvalds пишет: > On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> The _only_ thing that matters is that something broke. > To clarify: things like test programs etc don't matter. Real > applications, used by real users. That's what regressions cover. If > you have a workflow that isn't just some random kernel test thing, and > you depend on it, and we break it, the kernel is supposed to fix it. > > There are some (very few) exceptions. > > If it's a security issue, we may not be able to "fix" it, because > other concerns can obviously take precedence. > > Also, sometimes the reports come in way too late - if you were running > some stable distro kernel for several years, and updated, and notice a > change that happened four years ago and modern applications now rely > on the _new_ behavior, we may not be able to fix the regression any > more. > > But no, "it was an unintentional kernel bug and clearly just stupid > crap code, and we fixed it and now the kernel is much better and > cleaner" is not a valid reason for regressions. We'll go back to the > stupid and crap code if necessary, however much that may annoy us. IMHO at least such ocasions should be listed somewhere, and the software authors should be asked to fix their code. Then you'll be able to re-visit the problem later. It may be unreasonable to carry the compatibility hacks forever if the software that needed it, released the fix 10 years ago. In fact, in the cases I can remember, the kernel patches were never reverted, see this for instance: https://lkml.org/lkml/2005/3/26/21 And there were many other breakages too, for example when kernel started to use top-down memory allocations. These were because of the poor code in dosemu, and dosemu was asked to fix the code. I guess the policy to never break userspace was not existing back then. Or there is some margin below which the code quality is considered not worth the troubles. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Linus Torvalds <torvalds@linux-foundation.org> |
|---|---|
| Date | 2015-08-14 02:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pXaJk-2bP-29@gated-at.bofh.it> |
| In reply to | #1207246 |
On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev <stsp@list.ru> wrote:
> In fact, in the cases I can remember, the kernel patches
> were never reverted, see this for instance:
> https://lkml.org/lkml/2005/3/26/21
> And there were many other breakages too, for example when
> kernel started to use top-down memory allocations. These
> were because of the poor code in dosemu, and dosemu was
> asked to fix the code. I guess the policy to never break userspace
> was not existing back then. Or there is some margin below
> which the code quality is considered not worth the troubles. :)
Back in 2005 we may well not have been as strict about regressions as
we are now, no. The strict policy of no regressions actually
originally started mainly wrt suspend/resume issues, where the "fix
one machine, break another" kind of back-and-forth caused endless
problems, and meant that we didn't actually necessarily make any
forward progress, just moving a problem around.
(That said, I'd like to think that we've _always_ tried very hard to
not break stuff, it just wasn't necessarily the kind of very explicit
and hard rule that it is these days).
Also, there are certainly developers who push back on fixing the
regressions they caused. That is in fact the cause of some of my more
memorable explosions. But if I'm not brought into the discussion, and
the push-back happens on a mailing list, I may not even be aware of
the regression and the fact that a developer isn't willing to fix it.
I've also seen other projects be more willing to work around problems
like this than I personally would consider to be a good idea. For
example, we had some Wine regressions that broke a steam game or two,
and it was debugged on the steam and wine lists, and took a longish
time to actually even get to the attention of kernel people, because
the developers were actually willing to try to do an update and fix
their application to not do the thing that caused problems. Which I
certainly appreciate, but at the same time that doesn't necessarily
help the user who sits there with a game that just didn't work. So
even if an app is getting updated eventually, the kernel breakage
should be fixed.
So if some patch causes problems, and the author of the patch doesn't
acknowledge the problem or even if the application developer says "we
can work around that", always feel free to escalate the issue and
bring in upper maintainers.
That said, it *does* depend a bit on just how core the area is.
Sometimes it just gets too painful to fix things, and while the "no
regressions" rule is pretty damn close to the strictest rule we have,
there are never any completely absolute rules. As mentioned, there are
exceptions to the regression rule too, and sometimes the result might
just end up being "very few people are actually affected, and there's
a sufficiently good reason for the regression that we'll just cop
out".
But that should really be a very rare occurrence. We used to have
quite a lot of those kinds of issues with the GPU layer (resulting in
flag-days with the X server etc), and it really causes huge problems.
So there are no absolutes. But regressions are a serious problem, and
need to be treated as such. I will not _guarantee_ that we always fix
them, but I would hope we do our best.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 00:10 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX8Rc-7Xe-11@gated-at.bofh.it> |
| In reply to | #1207198 |
14.08.2015 00:46, Linus Torvalds пишет: > On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com> wrote: >> I am curious about what's supposed to happen normally on signal delivery. >> >> Is SS a register that's supposed to be preserved like EIP/RIP and CS when a >> signal is delivered? > What exactly does "supposed" mean? > > On x86-64, we traditionally haven't touched SS, because it doesn't > really matter in 64-bit long mode. And apparently dosemu depended on > that behavior. > > So clearly, we're not "supposed" to save/restore it. Because reality > matters a hell of a lot more than any theoretical arguments. Unless you introduce some clever flag to explicitly request its restoring. There is another problem as well which is that gcc assumes FS base to point to TLS at function prolog. Since FS is not restored too, the only suggestion I get is to write a sighandlers in asm... I wonder if someone really should write a sighandler in asm to restore FS base manually with a syscall. So I think the reality is asking for a new flag. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-14 00:20 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX90R-88q-1@gated-at.bofh.it> |
| In reply to | #1207204 |
On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev <stsp@list.ru> wrote: > 14.08.2015 00:46, Linus Torvalds пишет: >> >> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com> >> wrote: >>> >>> I am curious about what's supposed to happen normally on signal delivery. >>> >>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when >>> a >>> signal is delivered? >> >> What exactly does "supposed" mean? >> >> On x86-64, we traditionally haven't touched SS, because it doesn't >> really matter in 64-bit long mode. And apparently dosemu depended on >> that behavior. >> >> So clearly, we're not "supposed" to save/restore it. Because reality >> matters a hell of a lot more than any theoretical arguments. > > Unless you introduce some clever flag to explicitly request its restoring. > There is another problem as well which is that gcc assumes > FS base to point to TLS at function prolog. Since FS is not > restored too, the only suggestion I get is to write a sighandlers > in asm... I wonder if someone really should write a sighandler in > asm to restore FS base manually with a syscall. > So I think the reality is asking for a new flag. :) I still don't see how this hypothetical flag would work. The relevant task state consists of FS and the hidden FS base register. If you build with -fstack-protector, GCC really wants the FS base register to point to the right place. So you can't change it in the middle of a C function (because the prologue and epilogue will fail to match). Now suppose you set some magic flag and jump (via sigreturn, trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS and then gets #GP. You land in a signal handler. As far as the kernel's concerned, the FS base register is whatever the base of LDT entry 0 is. What else is the kernel supposed to shove in there? I think that making this work fully in the kernel would require a full-blown FS equivalent of sigaltstack, and that seems like overkill. Now, if it turns out that Oracle or whoever wants to write a JVM that uses WRFSBASE but still handles signals using standard C signal handlers, they're going to have the same problem. They, too, could fix it in libc, or someone could come up with an in-kernel mechanism that gets enabled at the same time as WRFSBASE and is careful not to break existing code. I really think that we want to have a single, coherent change whenever WRFSBASE and WRGSBASE get enabled that covers all the bases. None of the patch sets so far have done that. But this cuts both ways: I don't think we should change FS and GS behavior in signal handlers until we are confident that we know what's happening with the FSGSBASE instructions. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 00:30 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9ay-8jE-1@gated-at.bofh.it> |
| In reply to | #1207205 |
14.08.2015 01:11, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 00:46, Linus Torvalds пишет:
>>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com>
>>> wrote:
>>>> I am curious about what's supposed to happen normally on signal delivery.
>>>>
>>>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when
>>>> a
>>>> signal is delivered?
>>> What exactly does "supposed" mean?
>>>
>>> On x86-64, we traditionally haven't touched SS, because it doesn't
>>> really matter in 64-bit long mode. And apparently dosemu depended on
>>> that behavior.
>>>
>>> So clearly, we're not "supposed" to save/restore it. Because reality
>>> matters a hell of a lot more than any theoretical arguments.
>> Unless you introduce some clever flag to explicitly request its restoring.
>> There is another problem as well which is that gcc assumes
>> FS base to point to TLS at function prolog. Since FS is not
>> restored too, the only suggestion I get is to write a sighandlers
>> in asm... I wonder if someone really should write a sighandler in
>> asm to restore FS base manually with a syscall.
>> So I think the reality is asking for a new flag. :)
> I still don't see how this hypothetical flag would work.
>
> The relevant task state consists of FS and the hidden FS base
> register. If you build with -fstack-protector, GCC really wants the
> FS base register to point to the right place. So you can't change it
> in the middle of a C function (because the prologue and epilogue will
> fail to match).
>
> Now suppose you set some magic flag and jump (via sigreturn,
> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
> and then gets #GP. You land in a signal handler. As far as the
> kernel's concerned, the FS base register is whatever the base of LDT
> entry 0 is. What else is the kernel supposed to shove in there?
The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---
This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?
> I think that making this work fully in the kernel would require a
> full-blown FS equivalent of sigaltstack, and that seems like overkill.
Setting selector and base is what you call an "equivalent of sigaltstack"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2015-08-14 00:40 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9kd-8uM-17@gated-at.bofh.it> |
| In reply to | #1207207 |
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
> 14.08.2015 01:11, Andy Lutomirski пишет:
>
>> Now suppose you set some magic flag and jump (via sigreturn,
>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>> and then gets #GP. You land in a signal handler. As far as the
>> kernel's concerned, the FS base register is whatever the base of LDT
>> entry 0 is. What else is the kernel supposed to shove in there?
>
> The same as what happens when you do in userspace:
> ---
> asm ("mov $0,%%fs\n");
> prctl(ARCH_SET_FS, my_tls_base);
> ---
>
> This was the trick I did before gcc started to use FS in prolog,
> now I have to do this in asm.
> But how simpler for the kernel is to do the same?
>
>> I think that making this work fully in the kernel would require a
>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>
> Setting selector and base is what you call an "equivalent of sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Stas Sergeev <stsp@list.ru> |
|---|---|
| Date | 2015-08-14 01:00 +0200 |
| Subject | Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu |
| Message-ID | <pX9DA-q0-11@gated-at.bofh.it> |
| In reply to | #1207211 |
14.08.2015 01:29, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 01:11, Andy Lutomirski пишет:
>>
>>> Now suppose you set some magic flag and jump (via sigreturn,
>>> trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
>>> and then gets #GP. You land in a signal handler. As far as the
>>> kernel's concerned, the FS base register is whatever the base of LDT
>>> entry 0 is. What else is the kernel supposed to shove in there?
>> The same as what happens when you do in userspace:
>> ---
>> asm ("mov $0,%%fs\n");
>> prctl(ARCH_SET_FS, my_tls_base);
>> ---
>>
>> This was the trick I did before gcc started to use FS in prolog,
>> now I have to do this in asm.
>> But how simpler for the kernel is to do the same?
>>
>>> I think that making this work fully in the kernel would require a
>>> full-blown FS equivalent of sigaltstack, and that seems like overkill.
>> Setting selector and base is what you call an "equivalent of sigaltstack"?
> Yes. sigaltstack says "hey, kernel! here's my SP for signal
> handling." I think we'd need something similar to tell the kernel
> what my_tls_base is. Using the most recent thing passed to
> ARCH_SET_FS is no good because WRFSBASE systems might not use
> ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
> as we enable WRFSBASE.
If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.kernel
csiph-web