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 S1161250AbcBQLF2 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 17 Feb 2016 06:05:28 -0500
Received: from mail-wm0-f50.google.com ([74.125.82.50]:34471 "EHLO
	mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1161067AbcBQLF1 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 17 Feb 2016 06:05:27 -0500
Date: Wed, 17 Feb 2016 12:05:22 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Stas Sergeev <stsp@list.ru>
Cc: Andy Lutomirski <luto@kernel.org>, x86@kernel.org,
        Denys Vlasenko <dvlasenk@redhat.com>,
        Cyrill Gorcunov <gorcunov@gmail.com>,
        Pavel Emelyanov <xemul@parallels.com>, Brian Gerst <brgerst@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Oleg Nesterov <oleg@redhat.com>, Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH v5 1/4] x86/signal/64: Add a comment about sigcontext->fs
 and gs
Message-ID: <20160217110522.GA30222@gmail.com>
References: <cover.1455664054.git.luto@kernel.org>
 <baa78f3c84106fa5acbc319377b1850602f5deec.1455664054.git.luto@kernel.org>
 <20160217072122.GA19718@gmail.com>
 <56C44560.6010708@list.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <56C44560.6010708@list.ru>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Stas Sergeev <stsp@list.ru> wrote:

> 17.02.2016 10:21, Ingo Molnar пишет:
> > 
> > * Andy Lutomirski <luto@kernel.org> wrote:
> > 
> >> +	 * If the kernel ever adds explicit fs, gs, fsbase, and gsbase
> >> +	 * save/restore, it will most likely need to be opt-in and use
> >> +	 * different context slots.
> > 
> > Btw., that's not necessarily true: it could also be made opt-out, and a 
> > modify_ldt() or any other cleanly identifiable legacy usage/signature that is 
> > associated with DOSEMU might trigger the opt-out automatically as well.
> But there are the new versions of dosemu that still use
> "modify_ldt() or any other cleanly identifiable legacy usage/signature"
> and yet wants a new functionality.
> Please don't go for such an unreliable heuristic.

Only if implemented dumbly.

Implemented intelligently there would be 3 runtime states: enabled, disabled, 
automatic. New DOSEMU would explicitly enable it, which would override any 
automatic defaults.

But note that I was only pointing out that the comment is needlessly restrictive. 
Anyway, I have applied Andy's patches.

Thanks,

	Ingo