DPDK patches and discussions
 help / color / mirror / Atom feed
From: Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>
To: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org
Subject: Re: [RFC 8/8] ip_frag: fix gcc-12 warnings
Date: Wed, 8 Jun 2022 09:19:20 +0100	[thread overview]
Message-ID: <5549a996-a058-a9e4-f3f3-f31bfb198d6a@yandex.ru> (raw)
In-Reply-To: <20220607171746.461772-9-stephen@networkplumber.org>

07/06/2022 18:17, Stephen Hemminger пишет:
> The function rte_memcpy can derference past source buffer which
> will cause array out of bounds warnings. But there is no good reason
> to use rte_memcpy instead of memcpy in this code. Memcpy is just
> as fast for these small inputs, and compiler will optimize.


AFAIK, rte_memcpy() will outperform memcpy() when _size_ parameter
is a variable. Unfortunately that's exactly the case here.
So not sure it is a good change, at least without extensive perf testing.
BTW, if rte_memcpy() really access src buffer beyond it's boundaries,
I think that's definitely a bug that needs to be fixed.


> 
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
>   lib/ip_frag/rte_ipv4_fragmentation.c | 7 +++----
>   1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/lib/ip_frag/rte_ipv4_fragmentation.c b/lib/ip_frag/rte_ipv4_fragmentation.c
> index a19f6fda6408..27a8ad224dec 100644
> --- a/lib/ip_frag/rte_ipv4_fragmentation.c
> +++ b/lib/ip_frag/rte_ipv4_fragmentation.c
> @@ -5,7 +5,6 @@
>   #include <stddef.h>
>   #include <errno.h>
>   
> -#include <rte_memcpy.h>
>   #include <rte_ether.h>
>   
>   #include "ip_frag_common.h"
> @@ -26,7 +25,7 @@ static inline void __fill_ipv4hdr_frag(struct rte_ipv4_hdr *dst,
>   		const struct rte_ipv4_hdr *src, uint16_t header_len,
>   		uint16_t len, uint16_t fofs, uint16_t dofs, uint32_t mf)
>   {
> -	rte_memcpy(dst, src, header_len);
> +	memcpy(dst, src, header_len);
>   	fofs = (uint16_t)(fofs + (dofs >> RTE_IPV4_HDR_FO_SHIFT));
>   	fofs = (uint16_t)(fofs | mf << RTE_IPV4_HDR_MF_SHIFT);
>   	dst->fragment_offset = rte_cpu_to_be_16(fofs);
> @@ -48,7 +47,7 @@ static inline uint16_t __create_ipopt_frag_hdr(uint8_t *iph,
>   	struct rte_ipv4_hdr *iph_opt = (struct rte_ipv4_hdr *)ipopt_frag_hdr;
>   
>   	ipopt_len = 0;
> -	rte_memcpy(ipopt_frag_hdr, iph, sizeof(struct rte_ipv4_hdr));
> +	memcpy(ipopt_frag_hdr, iph, sizeof(struct rte_ipv4_hdr));
>   	ipopt_frag_hdr += sizeof(struct rte_ipv4_hdr);
>   
>   	uint8_t *p_opt = iph + sizeof(struct rte_ipv4_hdr);
> @@ -65,7 +64,7 @@ static inline uint16_t __create_ipopt_frag_hdr(uint8_t *iph,
>   			break;
>   
>   		if (RTE_IPV4_HDR_OPT_COPIED(*p_opt)) {
> -			rte_memcpy(ipopt_frag_hdr + ipopt_len,
> +			memcpy(ipopt_frag_hdr + ipopt_len,
>   				p_opt, p_opt[1]);
>   			ipopt_len += p_opt[1];
>   		}


  reply	other threads:[~2022-06-08  8:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07 17:17 [RFC 0/8] Gcc-12 warning fixes Stephen Hemminger
2022-06-07 17:17 ` [RFC 1/8] net/ena: fix warnings related to rte_memcpy and gcc-12 Stephen Hemminger
2022-06-08 12:29   ` Michał Krawczyk
2022-06-08 15:32     ` Stephen Hemminger
2022-06-08 19:18       ` Michał Krawczyk
2022-06-08 20:52         ` Stephen Hemminger
2022-06-07 17:17 ` [RFC 2/8] net/qede: fix gcc-12 rte_memcpy warnings Stephen Hemminger
2022-06-23 14:16   ` David Marchand
2022-06-07 17:17 ` [RFC 3/8] net/ice: fix rte_memcpy warnings with gcc-12 Stephen Hemminger
2022-06-07 17:17 ` [RFC 4/8] test/ipfrag: fix gcc-12 warnings Stephen Hemminger
2022-06-07 17:17 ` [RFC 5/8] test/ipsec: fix gcc-12 rte_memcpy warnings Stephen Hemminger
2022-06-07 17:17 ` [RFC 6/8] net/enetfc: fix array out of bounds warning Stephen Hemminger
2022-06-07 17:17 ` [RFC 7/8] vhost: replace rte_memcpy to fix warning Stephen Hemminger
2022-06-07 17:17 ` [RFC 8/8] ip_frag: fix gcc-12 warnings Stephen Hemminger
2022-06-08  8:19   ` Konstantin Ananyev [this message]
2022-06-08 15:26     ` Stephen Hemminger
2022-06-09  7:09       ` Morten Brørup
2022-06-14 21:20         ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5549a996-a058-a9e4-f3f3-f31bfb198d6a@yandex.ru \
    --to=konstantin.v.ananyev@yandex.ru \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).