From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932149AbbHMXn6 (ORCPT ); Thu, 13 Aug 2015 19:43:58 -0400 Received: from smtp52.i.mail.ru ([94.100.177.112]:45291 "EHLO smtp52.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754427AbbHMXn5 (ORCPT ); Thu, 13 Aug 2015 19:43:57 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Linus Torvalds , Raymond Jennings References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <20150813200823.GS2059@uranus> <55CD0F29.4070604@gmail.com> <55CD13A0.8060403@gmail.com> Cc: Cyrill Gorcunov , Andy Lutomirski , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55CD2BB7.5040406@list.ru> Date: Fri, 14 Aug 2015 02:43:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 14.08.2015 02:18, Linus Torvalds пишет: > On Thu, Aug 13, 2015 at 4:05 PM, Linus Torvalds > 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. IMHO at least such ocasions should be listed somewhere, and the software authors should be asked to fix their code. Then you'll be able to re-visit the problem later. It may be unreasonable to carry the compatibility hacks forever if the software that needed it, released the fix 10 years ago. In fact, in the cases I can remember, the kernel patches were never reverted, see this for instance: https://lkml.org/lkml/2005/3/26/21 And there were many other breakages too, for example when kernel started to use top-down memory allocations. These were because of the poor code in dosemu, and dosemu was asked to fix the code. I guess the policy to never break userspace was not existing back then. Or there is some margin below which the code quality is considered not worth the troubles. :)