Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754682AbbHNACP (ORCPT ); Thu, 13 Aug 2015 20:02:15 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:37368 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbHNACN (ORCPT ); Thu, 13 Aug 2015 20:02:13 -0400 MIME-Version: 1.0 In-Reply-To: <55CD2BB7.5040406@list.ru> References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <20150813200823.GS2059@uranus> <55CD0F29.4070604@gmail.com> <55CD13A0.8060403@gmail.com> <55CD2BB7.5040406@list.ru> Date: Thu, 13 Aug 2015 17:02:12 -0700 X-Google-Sender-Auth: B2rlfJK48qJRvejvbJnEepeDMew Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu From: Linus Torvalds To: Stas Sergeev Cc: Raymond Jennings , Cyrill Gorcunov , Andy Lutomirski , Pavel Emelyanov , Linux kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3557 Lines: 68 On Thu, Aug 13, 2015 at 4:43 PM, Stas Sergeev wrote: > 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. :) Back in 2005 we may well not have been as strict about regressions as we are now, no. The strict policy of no regressions actually originally started mainly wrt suspend/resume issues, where the "fix one machine, break another" kind of back-and-forth caused endless problems, and meant that we didn't actually necessarily make any forward progress, just moving a problem around. (That said, I'd like to think that we've _always_ tried very hard to not break stuff, it just wasn't necessarily the kind of very explicit and hard rule that it is these days). Also, there are certainly developers who push back on fixing the regressions they caused. That is in fact the cause of some of my more memorable explosions. But if I'm not brought into the discussion, and the push-back happens on a mailing list, I may not even be aware of the regression and the fact that a developer isn't willing to fix it. I've also seen other projects be more willing to work around problems like this than I personally would consider to be a good idea. For example, we had some Wine regressions that broke a steam game or two, and it was debugged on the steam and wine lists, and took a longish time to actually even get to the attention of kernel people, because the developers were actually willing to try to do an update and fix their application to not do the thing that caused problems. Which I certainly appreciate, but at the same time that doesn't necessarily help the user who sits there with a game that just didn't work. So even if an app is getting updated eventually, the kernel breakage should be fixed. So if some patch causes problems, and the author of the patch doesn't acknowledge the problem or even if the application developer says "we can work around that", always feel free to escalate the issue and bring in upper maintainers. That said, it *does* depend a bit on just how core the area is. Sometimes it just gets too painful to fix things, and while the "no regressions" rule is pretty damn close to the strictest rule we have, there are never any completely absolute rules. As mentioned, there are exceptions to the regression rule too, and sometimes the result might just end up being "very few people are actually affected, and there's a sufficiently good reason for the regression that we'll just cop out". But that should really be a very rare occurrence. We used to have quite a lot of those kinds of issues with the GPU layer (resulting in flag-days with the X server etc), and it really causes huge problems. So there are no absolutes. But regressions are a serious problem, and need to be treated as such. I will not _guarantee_ that we always fix them, but I would hope we do our best. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/