From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754413AbbHMTlI (ORCPT ); Thu, 13 Aug 2015 15:41:08 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:37815 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754114AbbHMTh6 (ORCPT ); Thu, 13 Aug 2015 15:37:58 -0400 MIME-Version: 1.0 In-Reply-To: <55CCEC6C.3000800@list.ru> References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <55CCE8A3.7020105@list.ru> <55CCEC6C.3000800@list.ru> Date: Thu, 13 Aug 2015 12:37:57 -0700 X-Google-Sender-Auth: -1xr4L40GMYTUHUZdrYGKwgFWa4 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: Andy Lutomirski , 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 On Thu, Aug 13, 2015 at 12:13 PM, Stas Sergeev 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. 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? (And no, we've not always succeeded in that "shouldn't cause problems" space. So I'm not claiming we have a perfect track record, but I do claim that I at least care very deeply) Linus