From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754061AbbHMTNx (ORCPT ); Thu, 13 Aug 2015 15:13:53 -0400 Received: from smtp17.mail.ru ([94.100.176.154]:44306 "EHLO smtp17.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753498AbbHMTNv (ORCPT ); Thu, 13 Aug 2015 15:13:51 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Andy Lutomirski References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <55CCE8A3.7020105@list.ru> Cc: Linus Torvalds , Linux kernel From: Stas Sergeev Message-ID: <55CCEC6C.3000800@list.ru> Date: Thu, 13 Aug 2015 22:13:48 +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:01, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 11:57 AM, Stas Sergeev wrote: >> 13.08.2015 21:35, Linus Torvalds пишет: >>> On Thu, Aug 13, 2015 at 10:51 AM, Stas Sergeev wrote: >>>> Hello Linus, I verified that patch-minimal.diff is enough >>>> to fix the problem, BUT! dosemu is in fact using the .fs and >>>> .gs fields of sigcontext as a placeholders. Why the minimal >>>> patch alone helps is simply because the kernel headers >>>> installed in a system do not yet represent the newer kernel >>>> developments and have the .fs and .gs fields in. >>> Ok. So I'm inclined to do the bigger revert, just to fix the compile >>> issue. It would be crazy to force some silly autoconf script for >>> random header info. >> But OTOH these fields already lost their meaning. >> It may make sense to force people to stop using them, >> in case you ever want to re-use them again in the future. >> From what Andy says, it seems there are the distant plans >> to start restoring FS again. If people still use sigcontext.fs >> by that time, you'll get problems. If you force everyone to >> stop using them - you'll be safe. > There are distant plans to think about restoring them, at least. But > it's not just FS -- it's FSBASE as well, and that's not going to fit > in the same slot. And we still don't get to break old DOSEMU versions > (knowingly, anyway). > >> In fact, I think the "silly autoconf script" you mentioned above, >> should indeed be reverted, and instead I should use >> sigcontext.reserved1[8] array to store FS/GS? Is this >> safer against ever re-using this space? Not sure... > Honestly, I'd just save it somewhere outside sigcontext. If it's > application data, treat it as such. OTOH, if you've already been > saving it in the old FS/GS slots, I see no great reason to change it. OK, as you promise not to re-use the same slots in the future, I won't change it. Thanks. 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.