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:59:59 EST

13.08.2015 22:37, Linus Torvalds ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
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.
I definitely care.

Compile issues may be slightly lower on my radar, but the basic rule
should be that upgrading a kernel shouldn't cause problems.
It doesn't: fedora provides a "sanitized up" version of sigcontext.h
in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64.
So it seems the "sanitized up" headers come from glibc, which
means all other distros would have that too.

The only exception is for stuff that gets very intimate with the
kernel itself - ie things like external modules etc. Those we don't
really try to cater to, or care about.

Things that actually include internal kernel headers tend to have just
themselves to blame and historically we really didn't care very much
(long long ago we had issues with ext3fs-tools etc until those kinds
of things just ended up making their own copies).

But the point of the uabi headers was that even _that_ is supposed to
actually work, at least for the limited case of those headers.. So if
a uabi header change causes problems, we really *should* care, because
otherwise, what was the point of that whole uabi rework, really?
I thought this is mainly to help glibc and distributors to
provide a sanitized-up versions.
If it was for something else, then this "something else" didn't
reach the user PCs yet. :) Fedora-22 still has the sanitized
version in the glibc-headers package, so no compilation break
because of your change was ever actually observed.
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