Re: [PATCH v2] x86/lib: Use REP MOVSB for large memcpy() on ERMS CPUs without FSRM

[Usama Arif <usama.arif@linux.dev>]

On Wed, 11 Nov 2026 01:16:37 +0000 Borislav Petkov <bp@alien8.de> wrote:

> On November 10, 2026 8:59:02 PM UTC, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >On Tue, 10 Nov 2026 at 12:18, H. Peter Anvin <hpa@zytor.com> wrote:
> >>
> >> On November 10, 2026 9:53:07 AM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >> >Let's not do that.
> >> >
> >> >Putting magic things like RET in alternatives is just a bad bad idea.
> >> >
> >> >               Linus
> >>
> >> Why is that, *given that it is in assembly*?
> >
> >It's assembly, but it's assembly that potentially gets rewritten.
> >objtool already knows about __x86_return_thunk being special (although
> >I think it's the _target_, not the call site, it cares about).
> >
> >I would like to not have magic in stuff that is in the alternatives
> >section. We've had issues with relocations etc before.
> >
> >That said, grepping a bit for this, it turns out we already seem to be
> >doing that in memmove_64.S, although it was hidden from my first grep:
> >
> >  #define CHECK_LEN     cmp $0x20, %rdx; jb 1f
> >  #define MEMMOVE_BYTES movq %rdx, %rcx; rep movsb; RET
> >  .Lmemmove_begin_forward:
> >        ALTERNATIVE_2 __stringify(CHECK_LEN), \
> >                      __stringify(CHECK_LEN; MEMMOVE_BYTES), X86_FEATURE_ERMS, \
> >                      __stringify(MEMMOVE_BYTES), X86_FEATURE_FSRM
> >
> >which is pretty disgusting. But I guess that train has passed..
> >
> >           Linus
> 
> Yah, I never liked this piece of gunk. Lemme give it a fresh look when things relax a bit...


I have sent v3 that doesnt put RET in an alternative [1]

[1] https://lore.kernel.org/all/20261111132214.2979125-3-usama.arif@linux.dev/#t