Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754318AbbHNTSd (ORCPT ); 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 ); Fri, 14 Aug 2015 15:18:31 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150814071500.GA2678@gmail.com> From: Andy Lutomirski Date: Fri, 14 Aug 2015 12:18:11 -0700 Message-ID: Subject: Re: [GIT PULL] x86 fixes To: Linus Torvalds Cc: Ingo Molnar , Juergen Gross , Andy Lutomirski , Linux Kernel Mailing List , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Brian Gerst , Denys Vlasenko , Andrew Morton Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1786 Lines: 39 On Fri, Aug 14, 2015 at 12:06 PM, Linus Torvalds wrote: > On Fri, Aug 14, 2015 at 11:57 AM, Linus Torvalds > 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 -- 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/