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

[David Laight <david.laight.linux@gmail.com>]

On Tue, 10 Nov 2026 12:59:02 -0800
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..

Or no one has realised it ran straight through the buffers :-)
RET is likely to be a 5 byte jmp instruction.
One of the checks for letting it be replaced by 0xc3,(0xcc)*4 is (addr & 0x20).
That will be wrong for the alternatives (half the time) so a quarter
of the time the train will go straight through the buffers.

David

> 
>            Linus