lkml.org 
[lkml]   [2022]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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?

\
 
 \ /
  Last update: 2022-03-30 16:45    [W:0.064 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site