From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753482AbbHMQek (ORCPT ); Thu, 13 Aug 2015 12:34:40 -0400 Received: from mail-ig0-f182.google.com ([209.85.213.182]:35293 "EHLO mail-ig0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753455AbbHMQeh (ORCPT ); Thu, 13 Aug 2015 12:34:37 -0400 MIME-Version: 1.0 In-Reply-To: References: <55CA90B4.2010205@list.ru> Date: Thu, 13 Aug 2015 09:34:36 -0700 X-Google-Sender-Auth: muulU0GTTPAO53RmIUG0WCiah48 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu From: Linus Torvalds To: Andy Lutomirski Cc: Stas Sergeev , 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 9:23 AM, Andy Lutomirski wrote: > On Thu, Aug 13, 2015 at 9:19 AM, Linus Torvalds > wrote: >> >> So how about this "alternate" minimal patch instead. The difference is: >> >> - we actually leave the >> >> regs->ss = __USER_DS; >> >> in __setup_rt_frame, to guarantee that when we take a signal, we do >> take it with a valid SS > > That by itself is enough to break DOSEMU. I think we may be stuck > with my hack to only replace regs->ss if the old one was invalid. Are you sure? From the description by Stas, the problem is literally the *restoring* action of the sigcontext, and trying to restore a SS value that is no longer valid. "The crash happens when DOS program terminates. At that point dosemu subverts the execution flow by replacing segregs and cs/ip ss/sp in sigcontext with its own. But __pad0 still has DOS SS, which crash because (presumably) the DOS LDT have been just removed" and my "truly-minimal" patch removes all of the sigcontext games. > You mean that we always set ss to __USER_DS on sigreturn? No. We never touch SS at sigreturn time at all. Only when entering the signal *handler* do we reset things to a known state. The signal handler can do anything it wants, and sigreturn won't touch it (which will obviously _leave_ it as __USER_DS, but avoids the problem with sigreturn trying to load an SS that is no longer valid) > If this regression were new in 4.2-rc, then I'd say revert first and > ask questions later, but the regression is in 4.1 as well :( Big deal. That's why we have the "cc stable". Distributions that ship with 4.1 are still fairly few (but it's a LTS release so it will grow) but they all pick up stable kernels. And even if they temporarily have a broken situation, it's still better to make sure that broken situation gets fixed, rather than say "oh well, too late to do anything about it now". Linus