Re: x86, possible bug in __memmove() alternatives patching

[Dave Hansen]

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?