Messages in this thread | | | Date | Tue, 29 Mar 2022 15:33:17 -0700 | From | Dave Hansen <> | Subject | Re: x86, possible bug in __memmove() alternatives patching |
| |
On 3/26/22 04:39, Matthias Welwarsky wrote: > >> But, we do try to make the kernel work even the face of funky >> hypervisors that do things that never occur on real hardware. If a nice >> patch to fix this up showed up, I'd definitely take a look. > The question is whether a sequence like this could be relevant: > > 0) CPU announces feature FSRM through cpuid > 1) BIOS/firmware disables fast string ops through IA32_MISC_ENABLE before > loading kernel (for whatever reason) > 2) Kernel populates features from cpuid > 3) Kernel clears ERMS based on IA32_MISC_ENABLE > 4) "alternatives" patching destroys __memmove()
Hi Matthias,
What does "destroys __memmove()" mean in practice? What's the end-user visible effect of this? Do they see a crash or just crummy performance?
| |