From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753907AbbHMTCG (ORCPT ); Thu, 13 Aug 2015 15:02:06 -0400 Received: from mail-ob0-f181.google.com ([209.85.214.181]:33290 "EHLO mail-ob0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753583AbbHMTCE convert rfc822-to-8bit (ORCPT ); Thu, 13 Aug 2015 15:02:04 -0400 MIME-Version: 1.0 In-Reply-To: <55CCE8A3.7020105@list.ru> References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <55CCE8A3.7020105@list.ru> From: Andy Lutomirski Date: Thu, 13 Aug 2015 12:01:42 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Stas Sergeev Cc: Linus Torvalds , Linux kernel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. --Andy -- Andy Lutomirski AMA Capital Management, LLC