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

From: Raymond Jennings
Date: Thu Aug 13 2015 - 19:35:41 EST

On 08/13/15 16:18, Linus Torvalds wrote:
On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> 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

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.

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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at