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 - 15:13:57 EST

13.08.2015 22:01, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
13.08.2015 21:35, Linus Torvalds ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
Hello Linus, I verified that patch-minimal.diff is enough
to fix the problem, BUT! dosemu is in fact using the .fs and
.gs fields of sigcontext as a placeholders. Why the minimal
patch alone helps is simply because the kernel headers
installed in a system do not yet represent the newer kernel
developments and have the .fs and .gs fields in.
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.
But OTOH these fields already lost their meaning.
It may make sense to force people to stop using them,
in case you ever want to re-use them again in the future.
From what Andy says, it seems there are the distant plans
to start restoring FS again. If people still use sigcontext.fs
by that time, you'll get problems. If you force everyone to
stop using them - you'll be safe.
There are distant plans to think about restoring them, at least. But
it's not just FS -- it's FSBASE as well, and that's not going to fit
in the same slot. And we still don't get to break old DOSEMU versions
(knowingly, anyway).

In fact, I think the "silly autoconf script" you mentioned above,
should indeed be reverted, and instead I should use
sigcontext.reserved1[8] array to store FS/GS? Is this
safer against ever re-using this space? Not sure...
Honestly, I'd just save it somewhere outside sigcontext. If it's
application data, treat it as such. OTOH, if you've already been
saving it in the old FS/GS slots, I see no great reason to change it.
OK, as you promise not to re-use the same slots in the future,
I won't change it. Thanks.
As for the compilation failure - I am surprised you even care.
I thought the "we don't break userspace" covers only run-time,
not compile-time. Oh well.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at