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 S1754318AbbHNTSd (ORCPT <rfc822;w@1wt.eu>);
	Fri, 14 Aug 2015 15:18:33 -0400
Received: from mail-oi0-f50.google.com ([209.85.218.50]:36269 "EHLO
	mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750735AbbHNTSb (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 14 Aug 2015 15:18:31 -0400
MIME-Version: 1.0
In-Reply-To: <CA+55aFzXMSZmA98whHXAx8DK_35TxLzjy7uTsRMKT=PzabojKA@mail.gmail.com>
References: <20150814071500.GA2678@gmail.com> <CA+55aFwP6gJ5Qh7btvf_gME35nvR-se==MuRcvctDqdxEQ9SJA@mail.gmail.com>
 <CALCETrUcTKVw+ke0FuhgfE2d5MrxYJyN4fwkuHUJfGVyF0GiyQ@mail.gmail.com>
 <CA+55aFypRuAxvp5BKd87fmFFSccH0bvhUkZ5ST2z_-Ut1ywjEw@mail.gmail.com> <CA+55aFzXMSZmA98whHXAx8DK_35TxLzjy7uTsRMKT=PzabojKA@mail.gmail.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 14 Aug 2015 12:18:11 -0700
Message-ID: <CALCETrX-dcYz8Tn7Ke4--riZvHPsRQGN5aKG=8g7WEA1YZYVKQ@mail.gmail.com>
Subject: Re: [GIT PULL] x86 fixes
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>, Juergen Gross <jgross@suse.com>,
        Andy Lutomirski <luto@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Brian Gerst <brgerst@gmail.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Aug 14, 2015 at 12:06 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Aug 14, 2015 at 11:57 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> That code seems fine to me (and explicitly errors out when it's not in
>> the LDT). FPU_CS is actually the CS selector value.
>>
>> So testing that for being in the LDT by checking bit #2, and then
>> using FPU_get_ldt_descriptor() on it actually seems *correct*.
>>
>> It's the actual instruction data segment handling that looks entirely
>> broken, and was explicitly made *more* broken by that commit.
>
> Note that in practice, it's *probably* true that if CS ends up being
> in the LDT (so we're running something odd like Wine), then *probably*
> the data segments are going to be in the LDT too. So the old code that
> unconditionally looked things up in the LDT probably worked in
> practice, even if it was wrong.
>
> The new code cannot *possibly* work at all, because even if the data
> segment register is in the LDT, it uses the wrong thing to look up the
> LDT entry, so it will get the wrong base.
>
> But as mentioned, it will only *matter* on something like a 486SX, and
> only when the whole "CS/DS didn't match the default flat segments"
> case triggers, so not only do you have to run on a 486SX, you will
> have to run something like Wine on it. So it sounds very very unlikely
> that this bug matters in practice.

Unless I'm missing something, it's literally a one-line fix -- just
put the missing PM_REG_(segment) back in.

--Andy