From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932088AbbHMT75 (ORCPT ); Thu, 13 Aug 2015 15:59:57 -0400 Received: from smtp2.mail.ru ([94.100.179.91]:39178 "EHLO smtp2.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752061AbbHMT74 (ORCPT ); Thu, 13 Aug 2015 15:59:56 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Linus Torvalds References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <55CCE8A3.7020105@list.ru> <55CCEC6C.3000800@list.ru> Cc: Andy Lutomirski , Linux kernel From: Stas Sergeev Message-ID: <55CCF733.70507@list.ru> Date: Thu, 13 Aug 2015 22:59:47 +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 13.08.2015 22:37, Linus Torvalds пишет: > 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. It doesn't: fedora provides a "sanitized up" version of sigcontext.h in /usr/include/bits, which comes from glibc-headers-2.21-7.fc22.x86_64. So it seems the "sanitized up" headers come from glibc, which means all other distros would have that too. > 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? I thought this is mainly to help glibc and distributors to provide a sanitized-up versions. If it was for something else, then this "something else" didn't reach the user PCs yet. :) Fedora-22 still has the sanitized version in the glibc-headers package, so no compilation break because of your change was ever actually observed.