From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754166AbbHMUKD (ORCPT ); Thu, 13 Aug 2015 16:10:03 -0400 Received: from smtp10.mail.ru ([94.100.181.92]:40411 "EHLO smtp10.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752866AbbHMUJs (ORCPT ); Thu, 13 Aug 2015 16:09:48 -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> <55CCEA73.1030403@list.ru> Cc: "linux-kernel@vger.kernel.org" , Linus Torvalds From: Stas Sergeev Message-ID: <55CCF988.3080702@list.ru> Date: Thu, 13 Aug 2015 23:09:44 +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:49, Andy Lutomirski пишет: > On Aug 13, 2015 12:05 PM, "Stas Sergeev" wrote: >> 13.08.2015 21:41, Andy Lutomirski пишет: >> >>> Stas: I think uc_flags is okay. We don't currently read it during >>> sigreturn, but I see no reason that we can't start reading it. >> Andy, we definitely have some communication discontinuity here. :) >> The point is not sigreturn. If we are talking about the flags that >> will in the future control also TLS, how would you limit it to sigreturn()? >> It should control the restoring of FS _on signal delivery_, not only >> on sigreturn()! So how uc_flags can be used for this at all? > Ah, you want it restored on signal delivery. What would it be > restored to? Null descriptor and TLS base in MSR I guess, no? > ISTM that can be done easily enough in user code, so > maybe we should leave it to user code. But it is actually not. gcc relies of fs pointing to TLS on the function prolog, so the asm signal handlers again? And there are just too many trickery for an asm handler. Should it do the syscall to set fs base via MSR? And to what value? Why do you think the user should mess with all this pain? It is just much easier to do on a kernel side, is it not? And IMHO this is the kernel's responsibility to adhere to the ABI constraints when entering the signal handler, and the ABI says fs should point to TLS.