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

[Dave Hansen <dave.hansen@intel.com>]

On 3/30/22 06:56, Matthias Welwarsky wrote:
> 
> Here's the relevant bits:
> 
>         /* FSRM implies ERMS => no length checks, do the copy directly */
> .Lmemmove_begin_forward:
>         ALTERNATIVE "cmp $0x20, %rdx; jb 1f", "", X86_FEATURE_FSRM
>         ALTERNATIVE "", __stringify(movq %rdx, %rcx; rep movsb; RET), 
> X86_FEATURE_ERMS
> 
> If FSRM is there but ERMS isn't, the first ALTERNATIVE is activated but not 
> the second one. That means the length check (< 32) and subsequent "jb 1f" is 
> suppressed but the "movq %rdx, %rcx; rep movsb; RET" is also not there. 

Ahh, thanks for the explanation.  It would help if I wasn't reading the
code wrong.

> I'll send a patch. I think the same rationale applies to FSRM as to ERMS, 
> which gets manually cleared when IA32_MISC_ENABLE says that fast string ops 
> are not available. It will be a one liner added to the dependency table in 
> cpu-deps.c, making FSRM depend on ERMS so that it gets automatically cleared.

Sounds good.  Could you also add some of that explanation to a comment
__memmove and basically say that the code is broken if the dependency
isn't enforced?