[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwP6gJ5Qh7btvf_gME35nvR-se==MuRcvctDqdxEQ9SJA@mail.gmail.com>
Date: Fri, 14 Aug 2015 11:25:15 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...nel.org>, Juergen Gross <jgross@...e.com>,
Andy Lutomirski <luto@...nel.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86 fixes
On Fri, Aug 14, 2015 at 12:15 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> Please pull the latest x86-urgent-for-linus git tree from:
Nope. It seems to be an unmitigated disaster, as far as I can tell.
> +static inline struct desc_struct FPU_get_ldt_descriptor(unsigned seg)
> +{
> + static struct desc_struct zero_desc;
> + struct desc_struct ret = zero_desc;
> +
> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
> + seg >>= 3;
So this seems to take the actual segment selector, and look it up in
the LDT. (Why only the LDT?)
However:
> + descriptor = FPU_get_ldt_descriptor(segment);
as far as I can tell, the "segment" here is the segment _register_
number, not the segment selector.
The segment selector is in "addr->selector", and furthermore I'm not
at all convinced that it is in the LDT to begin with. I'd expect the
common case to be that it's in the GDT, in fact. But what do I know..
Anyway, I may be embarrassingly wrong, and if I am, feel free to shout
bad words at me, but that code seems to be utter crap.
Not that the old code was particularly good either, but at least that
PM_REG_(segment) that *used* to exist there would translate segment
register numbers into actual selector values (even if it would get the
FS case wrong).
Now that said, I doubt anybody cares. Since we don't support the
original 80386, the only way to ever trigger FP emulation is by having
a 486SX or possibly a couple of even rarer clone chips. So it's not
like the fact that the code is completely wrong and crap actually
*matters*, but I still refuse to pull stuff that seems to be so
completely screwed up.
And this commit is even marked as "reviewed". Are you guys really
seeing something that I'm not? Am I somehow wrong in thinking it's
entirely broken?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists