From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753937AbbHMSgN (ORCPT <rfc822;w@1wt.eu>);
	Thu, 13 Aug 2015 14:36:13 -0400
Received: from smtp51.i.mail.ru ([94.100.177.111]:51715 "EHLO smtp51.i.mail.ru"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753869AbbHMSgK (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 13 Aug 2015 14:36:10 -0400
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu
To: Andy Lutomirski <luto@amacapital.net>
References: <55CBA4CE.1040108@list.ru> <20150813083949.GA17091@gmail.com>
 <55CC911D.3080607@list.ru>
 <CALCETrV9K0sjmWbagorUuwVUPd6bmvELEVScqs-uejDsM84EjA@mail.gmail.com>
 <55CCB625.3000900@list.ru>
 <CALCETrUsBSt6kUgh00sut0V4JbY4aF-5Nr52FhfS88Z39Fm_gA@mail.gmail.com>
 <55CCBFDC.5000207@list.ru>
 <CALCETrUECup8foRfkcf==tXYO=Vpgp+Tc6PStJmOHKRrsDkS5w@mail.gmail.com>
 <55CCC3E1.9060603@list.ru>
 <CALCETrWo6WSykpef0f9Nfrt7wUhPcePESff6h4hak_ffAMkbzA@mail.gmail.com>
 <55CCC812.5010101@list.ru>
 <CALCETrVg43=e05BW7S7BXOC3ei4gd1RbJcsiHti_V5ttbhPZTQ@mail.gmail.com>
 <55CCCA78.8030806@list.ru>
 <CALCETrXJsQ6p-5OUB1+Gsi3NMpRv5_HR8ru-nqwMfxykLrAERA@mail.gmail.com>
 <55CCD054.5020600@list.ru>
 <CALCETrUhrYJJ=_L-cBbhxjfWJhvqHpv2wfNt034erw5n6PaTyw@mail.gmail.com>
 <55CCDB55.3040803@list.ru>
 <CALCETrWB6Xfyg7Z49tQ9M3+HadWaCaf5gexRyQYNNQso796yyQ@mail.gmail.com>
 <55CCDFC2.1000503@list.ru>
 <CALCETrV9YsdR561=YmQbjGCoC1LSHBwO=n05AZiQC_WiQPtaHw@mail.gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>, X86 ML <x86@kernel.org>,
        Linux kernel <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>,
        Brian Gerst <brgerst@gmail.com>, Borislav Petkov <bp@alien8.de>,
        Stas Sergeev <stsp@users.sourceforge.net>
From: Stas Sergeev <stsp@list.ru>
Message-ID: <55CCE38C.9030107@list.ru>
Date: Thu, 13 Aug 2015 21:35:56 +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: <CALCETrV9YsdR561=YmQbjGCoC1LSHBwO=n05AZiQC_WiQPtaHw@mail.gmail.com>
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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

13.08.2015 21:25, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 11:19 AM, Stas Sergeev <stsp@list.ru> wrote:
>
>> It is more about selecting the right field for such a flag.
>> You can select the right field now, and introduce some flag
>> to it, like SIG_SAVE_SS or whatever. This will fix a regression.
>> Then, when the TLS time will code, you'll just add SIG_SAVE_FS
>> flag to the same field, so that they can be ORed.
> Oh.
>
> I think the field is obvious: uc_flags.
But Andy, I don't understand...
If we are talking about the field that will in the future also
cover TLS, how can this be uc_flags? By using uc_flags,
how will you control the restoring of FS on signal delivery?

>    I also thing that all of the
> saving should happen automatically, since I still don't see how
> anything will break if the kernel starts saving more things.  It's the
> restore part that's problematic.
OK, so SIG_RESTORE_SS and SIG_RESTORE_FS.
How can those be the part of uc_flags, if we want to
control the restoring _on a signal delivery_?