On Fri, Aug 14, 2015 at 12:06 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Fri, Aug 14, 2015 at 11:57 AM, Linus Torvalds > <torva...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/