The new Haswell microcode update[1] removes the "hle" (hardware lock elision) processor capability. And it is not cosmetic, either: Intel TSX opcodes will cause an illegal opcode trap after the microcode update[2].
This means cpu_info()->x86_capability becomes stale after the microcode update. We could add logic to compute the new x86_capability after a microcode update run, and OOPS the kernel if something too important (i.e. anything the kernel uses) went away. Otherwise, refresh cpu_info()->x86_capability. Is that doable? [1] sig 0x000306f2, pf mask 0x6f, 2014-09-03, rev 0x0029, size 28672 sig 0x000306c3, pf mask 0x32, 2014-07-03, rev 0x001c, size 21504 sig 0x00040651, pf mask 0x72, 2014-07-03, rev 0x001c, size 20480 sig 0x00040661, pf mask 0x32, 2014-07-03, rev 0x0012, size 23552 [2] instantly segfaulting every running process using libpthread-2.19, as well as any other users of Intel TSX. https://bugs.launchpad.net/intel/+bug/1370352 And yes, this means we will kill support for microcode updates outside of the initramfs/early-initramfs, at least in Debian, and likely in Ubuntu. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/