+To: x86 maintainers, another bug in rte_memcpy()

> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Saturday, 2 March 2024 18.02
> 
> On Sat, 2 Mar 2024 12:19:13 +0100
> Mattias Rönnblom <hof...@lysator.liu.se> wrote:
> 
> > On 2024-03-01 18:14, Stephen Hemminger wrote:
> > > Rte_memcpy should not be used for the simple case of copying
> > > a fix size structure because it is slower and will hide problems
> > > from code analysis tools. Coverity, fortify and other analyzers
> > > special case memcpy().
> > >
> > > Gcc (and Clang) are smart enough to inline copies which
> > > will be faster.
> > >
> >
> > Are you suggesting rte_memcpy() calls aren't inlined?
> 
> With a simple made up example of copying an IPv6 address.
> 
> rte_memcpy() inlines to:
> rte_copy_addr:
>         movdqu  xmm0, XMMWORD PTR [rsi]
>         movups  XMMWORD PTR [rdi], xmm0
>         movdqu  xmm0, XMMWORD PTR [rsi]
>         movups  XMMWORD PTR [rdi], xmm0
>         ret
> 
> Vs memcpy becomes.
> 
> copy_addr:
>         movdqu  xmm0, XMMWORD PTR [rsi]
>         movups  XMMWORD PTR [rdi], xmm0
>         ret
> 
> Looks like a bug in rte_memcpy_generic? Why is it not handling
> 16 bytes correctly.

Looks like you have run into another bunch of off-by-one errors like this one:
https://git.dpdk.org/dpdk/commit/lib/eal/x86/include/rte_memcpy.h?id=2ef17be88e8b26f871cfb0265227341e36f486ea

> 
> For me, it was more about getting fortify and compiler warnings to
> catch bugs. For most code, the output should be the same.

Reply via email to