Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev]

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