Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751722AbbHLU3S (ORCPT ); Wed, 12 Aug 2015 16:29:18 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:36570 "EHLO mail-ob0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750767AbbHLU3R convert rfc822-to-8bit (ORCPT ); Wed, 12 Aug 2015 16:29:17 -0400 MIME-Version: 1.0 In-Reply-To: <55CBA909.3020306@list.ru> References: <55CA90B4.2010205@list.ru> <55CAFD9F.2070001@list.ru> <55CB7BAE.9090503@list.ru> <55CB9697.1050602@list.ru> <55CBA4CE.1040108@list.ru> <55CBA909.3020306@list.ru> From: Andy Lutomirski Date: Wed, 12 Aug 2015 13:28:57 -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: X86 ML , 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 Content-Length: 2377 Lines: 59 On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev wrote: > 12.08.2015 23:01, Andy Lutomirski пишет: >> >> On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev wrote: >>> >>> 12.08.2015 22:20, Andy Lutomirski пишет: >>>> >>>> current kernels, it stays switched. If we change this, it won't stay >>>> switched. Even ignoring old ABI, it's not really clear to me what the >>>> right thing to do is. >>> >>> There can be the following cases: >>> - switch_userspace_thread() switches fs to non-zero selector >>> - switch_userspace_thread() switches the fs base via syscall >>> - switch_userspace_thread() switches fs in sigcontext >>> - switch_userspace_thread() switches fs_base in sigcontext (???) >>> What exactly case do you have in mind? >>> I'd say, the way x86_32 is doing things - is good, but the >>> bases... perhaps, in ideal world, they should be a part of >>> the sigcontext as well? >> >> Any of the above. What do you want the kernel to do, and how does the >> kernel know you want to do that? The kernel has to pick *some* >> semantics here. > > Assuming the bases are made the part of a sigcontext, > I'd say there would be no ambiguities remained at all: > whatever you change in a sigcontext, will be "applied" by > the sigreturn(). Whatever you put in the registers > (either segregs or MSRs), is valid until sigreturn(), then > forgotten forever. > The mess only comes in when some things are part of > sigcontext and some are not. But if you have _all_ things > accessable in sigcontext, then the user has a way of expressing > his needs very clearly: he'll either touch sigcontext or direct > values, depending on what he need. > > Is this right? Maybe, except that doing this might break existing code (Wine and Java come to mind). I'm not really sure. Anyway, can you give this and its parent a try: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/sigcontext&id=83a08d8c3f43c5524ffc0d88c0eff747716696f5 If they fix the problem for you, I'll improve the test cases and send them to -stable. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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/