Messages in this thread | | | Date | Wed, 30 Mar 2022 07:44:14 -0700 | From | Dave Hansen <> | Subject | Re: x86, possible bug in __memmove() alternatives patching |
| |
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?
| |