[PATCH v2 01/71] cocci/rte_memcpy: add script to eliminate fixed size rte_memcpy
Morten Brørup
mb at smartsharesystems.com
Sat Mar 2 18:39:45 CET 2024
+To: x86 maintainers, another bug in rte_memcpy()
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Saturday, 2 March 2024 18.02
>
> On Sat, 2 Mar 2024 12:19:13 +0100
> Mattias Rönnblom <hofors at 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.
More information about the dev
mailing list