Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752950AbbHSKKL (ORCPT ); Wed, 19 Aug 2015 06:10:11 -0400 Received: from smtp38.i.mail.ru ([94.100.177.98]:52969 "EHLO smtp38.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbbHSKKJ (ORCPT ); Wed, 19 Aug 2015 06:10:09 -0400 Message-ID: <55D455FA.20903@list.ru> Date: Wed, 19 Aug 2015 13:10:02 +0300 From: Stas Sergeev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Brian Gerst , Linux kernel Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu References: <55CA90B4.2010205@list.ru> <55D2D0DE.3080707@list.ru> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4178 Lines: 91 19.08.2015 01:42, Andy Lutomirski пишет: > On Mon, Aug 17, 2015 at 11:29 PM, Stas Sergeev wrote: >> 13.08.2015 20:00, Brian Gerst пишет: >> >>> On Thu, Aug 13, 2015 at 11:43 AM, Andy Lutomirski >>> wrote: >>>> >>>> On Thu, Aug 13, 2015 at 8:37 AM, Linus Torvalds >>>> wrote: >>>>> >>>>> On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote: >>>>>> >>>>>> I realize this patch may be good to have in general, but >>>>>> breaking userspace without a single warning is a bit >>>>>> discouraging. Seems like the old "we don't break userspace" >>>>>> rule have gone. >>>>> >>>>> That rule hasn't gone anywhere. >>>>> >>>>> Does a plain revert just fix everything? Because if so, that's the >>>>> right thing to do, and we can just re-visit this later. >>>>> >>>>> I don't understand why Andy and Ingo are even discussing this. What >>>>> the f*ck, guys? >>>>> >>>> I'm trying to fix it without reverting. If that doesn't work, then we >>>> revert. Yesterday, I thought I had a reasonably clean fix, but it >>>> turned out that it only solved half of the problem. >>>> >>>> If we revert, I think I need to check what will break due to the >>>> revert. I need to check at least Wine, and we'll have to do something >>>> about all the selftests that will start failing. I also need to check >>>> CRIU, and IIRC CRIU has started using the new sigcontext SS in new >>>> versions. >>> >>> I don't think Wine will be a problem, at least how it is currently set >>> up. 16-bit support is only in the 32-bit build. The 64-bit build >>> only supports Win64 apps, and will call the 32-bit version (installed >>> in parallel) to run 32 and 16-bit apps. >> >> Is this also because of the lack of the proper 32/16bit support in >> a 64bit kernels? If so, dosemu's work-arounds do not look like the >> too bad thing compared to that. :) > > What do you mean lack of proper 32/16 bit support? At least the following: 1. vm86(). There was a patch: http://v86-64.sourceforge.net/ Afaik rejected by Andi Kleen (likely for a good reason - too complex). There is some kvm-based alternative which IIRC was called by dosemu authors as "too slow", and so they started to use a jit-compiler. Wine have started to use dosbox for the DOS progs AFAIK. So both projects have a work-arounds to this limitation with which they are happy, and so it probably not worth the re-visiting. 2. espfix64. Its there since 3.16, but dosemu have lots of work-arounds in its code. The iret trampoline, for example, uses the carefully aligned stack page, where the high word of ESP is zero. Another part of the work-around is in a sighandler to decode the instruction to figure out what register caused a fault (corrupted esp value usually goes into ebp first, then to other regs) and zero out the high word of that, plus the high word of esp. There are also other bits of the work-around spread around the dosemu code, and I am surprised it actually even works! 3. SS problem. Was fixed in some versions of 4.1; not fixed any more. ;) dosemu did a glorious iret work-around. 4. FS problem. Worked around by autoconf checks to ban some gcc options, plus some special care when accessing thread-local vars in a sighandler. While your suggestion is to write an asm handlers, to the date I don't think anyone did that. It is easier to work-around it by other means. Maybe if you show an example of such handler, the things will change, but it is simpler to just wait for a kernel fix IMHO. This is what I called a 32/16bit support, and in fact, when I installed dosemu on a 64bit machine, started win31 and it just worked, I immediately wrote my regards to Bart Oldeman, so much I was impressed - I thought it is absolutely impossible to make this whole mess working reliably. I guess wine authors just were not as brave and decided to wait for the kernel functionality in place. -- 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/