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

[Linus Torvalds <torvalds@linux-foundation.org>]

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