All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: David Marchand <david.marchand@redhat.com>,
	Bruce Richardson <bruce.richardson@intel.com>
Cc: dev <dev@dpdk.org>, Thomas Monjalon <thomas@monjalon.net>,
	Ferruh Yigit <ferruh.yigit@xilinx.com>,
	dpdk stable <stable@dpdk.org>,
	Konstantin Ananyev <konstantin.v.ananyev@yandex.ru>,
	Bernard Iremonger <bernard.iremonger@intel.com>
Subject: Re: [PATCH 12/12] test/ipsec: fix build with GCC 12
Date: Fri, 3 Jun 2022 16:57:21 +0100	[thread overview]
Message-ID: <1f0bee5c-56c5-11f1-5452-5aa6c00d2acc@intel.com> (raw)
In-Reply-To: <CAJFAV8znp_xggffE5osuSB24U6nPXx7gL1k30DhnePFOniKRVg@mail.gmail.com>

Hi David,

On 03/06/2022 10:41, David Marchand wrote:
> On Fri, Jun 3, 2022 at 9:56 AM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
>>
>> On Fri, Jun 03, 2022 at 09:45:45AM +0200, David Marchand wrote:
>>> Hello Vladimir,
>>>
>>> On Thu, Jun 2, 2022 at 8:42 PM Medvedkin, Vladimir
>>> <vladimir.medvedkin@intel.com> wrote:
>>>>>                if (!dst) {
>>>>>                        rte_pktmbuf_free(m);
>>>>>                        return NULL;
>>>>>                }
>>>>> -             if (string != NULL)
>>>>> -                     rte_memcpy(dst, string, t_len);
>>>>> -             else
>>>>> -                     memset(dst, 0, t_len);
>>>>> +             if (string != NULL) {
>>>>> +                     size_t off;
>>>>> +
>>>>> +                     for (off = 0; off + string_len < len; off += string_len)
>>>>
>>>> I think it should be off + string_len <= len here, because otherwise, if
>>>> len is a multiple of string_len, the last ret_memcpy (after this loop)
>>>> will copy 0 bytes.
>>>
>>> Changing to off + string_len <= len would trigger an oob access to dst
>>> (by one extra byte)?
>>> Otoh, I don't think it is an issue to have a 0-length call to rte_memcpy.
>>>

The problem here is that if, for example, string_len is 8 bytes and len 
is 16, then it will write only 8 bytes.

>> Given this is test code, do we need rte_memcpy for performance over regular
>> libc memcpy? Does fixing the warning become any easier or clearer if libc
>> memcpy is used?
> 
> There was a similar proposal in vhost/crypto code.
> I am not a fan to switching to libc memcpy.
> We would be waiving a potential issue in rte_memcpy itself (which
> could also be a problem in how gcc understands this inlined code) or
> in the rte_memcpy caller code.
> 
> Here, gcc is probably too picky.
> No path currently leads to oob access on the src string.
> 
> Adding a simple hint (see simplified hunk below) seems to help gcc enough:
> 
> @@ -554,12 +554,14 @@ struct rte_ipv4_hdr ipv4_outer  = {
>   };
> 
>   static struct rte_mbuf *
> -setup_test_string(struct rte_mempool *mpool,
> -        const char *string, size_t len, uint8_t blocksize)
> +setup_test_string(struct rte_mempool *mpool, const char *string,
> +    size_t string_len, size_t len, uint8_t blocksize)
>   {
>       struct rte_mbuf *m = rte_pktmbuf_alloc(mpool);
>       size_t t_len = len - (blocksize ? (len % blocksize) : 0);
> 
> +    RTE_VERIFY(len <= string_len);
> +

RTE_VERIFY looks better here to make picky GCC happy.

> 
>       if (m) {
>           memset(m->buf_addr, 0, m->buf_len);
> 
> 

-- 
Regards,
Vladimir

  reply	other threads:[~2022-06-03 15:57 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-18 10:16 [PATCH 00/12] Fix compilation with gcc 12 David Marchand
2022-05-18 10:16 ` [PATCH 01/12] common/cpt: fix build with GCC 12 David Marchand
2022-05-20 20:23   ` Stephen Hemminger
2022-06-10 13:11   ` David Marchand
2022-06-13 11:40     ` [EXT] " Ankur Dwivedi
2022-06-16  9:30       ` David Marchand
2022-06-16 11:59         ` Ankur Dwivedi
2022-05-18 10:16 ` [PATCH 02/12] crypto/cnxk: " David Marchand
2022-05-20 20:24   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 03/12] crypto/ipsec_mb: " David Marchand
2022-06-02  9:50   ` Bruce Richardson
2022-06-10 13:07     ` David Marchand
2022-06-11 15:34   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 04/12] net/ena: " David Marchand
2022-05-20 20:28   ` Stephen Hemminger
2022-05-21  9:49     ` Morten Brørup
2022-05-21 16:23       ` Stephen Hemminger
2022-05-22 20:30         ` Morten Brørup
2022-06-11 15:34   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 05/12] net/enetfec: " David Marchand
2022-06-10 13:08   ` David Marchand
2022-06-13  5:22     ` Sachin Saxena (OSS)
2022-06-14  8:16     ` Sachin Saxena (OSS)
2022-06-11 15:35   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 06/12] net/ice: " David Marchand
2022-06-11 15:36   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 07/12] net/ice/base: " David Marchand
2022-05-18 10:16 ` [PATCH 08/12] net/qede/base: " David Marchand
2022-05-20 20:29   ` Stephen Hemminger
2022-06-21 23:17   ` Stephen Hemminger
2022-06-22 15:42     ` David Marchand
2022-05-18 10:16 ` [PATCH 09/12] vdpa/ifc: " David Marchand
2022-05-18 11:48   ` Wang, Xiao W
2022-06-11 15:36   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 10/12] vhost/crypto: " David Marchand
2022-06-02 10:08   ` Bruce Richardson
2022-06-14  9:22     ` David Marchand
2022-06-14  9:25       ` Bruce Richardson
2022-06-16  9:27         ` David Marchand
2022-06-11 15:36   ` Stephen Hemminger
2022-06-16  9:32   ` [PATCH v2] " David Marchand
2022-06-16 14:53     ` David Marchand
2022-05-18 10:16 ` [PATCH 11/12] app/flow-perf: " David Marchand
2022-06-02 10:21   ` Bruce Richardson
2022-06-08  9:03   ` Wisam Monther
2022-06-08 12:20     ` David Marchand
2022-06-13  7:49       ` Wisam Monther
2022-06-11 15:37   ` Stephen Hemminger
2022-05-18 10:16 ` [PATCH 12/12] test/ipsec: " David Marchand
2022-06-02 18:41   ` Medvedkin, Vladimir
2022-06-03  7:45     ` David Marchand
2022-06-03  7:56       ` Bruce Richardson
2022-06-03  9:41         ` David Marchand
2022-06-03 15:57           ` Medvedkin, Vladimir [this message]
2022-06-11 15:38   ` Stephen Hemminger
2022-06-16  9:33   ` [PATCH v2] " David Marchand
2022-06-17 12:06     ` David Marchand
2022-06-20  9:07       ` [EXT] " Akhil Goyal
2022-06-20 15:06       ` Medvedkin, Vladimir
2022-06-16 14:46   ` [PATCH v3] vhost/crypto: " David Marchand
2022-06-17 13:59     ` Maxime Coquelin
2022-06-21  9:31     ` Maxime Coquelin
2022-06-22  9:01       ` Poczatek, Jakub
2022-06-22  9:26         ` Zhang, Roy Fan
2022-06-22 14:07         ` David Marchand
2022-06-22 15:21           ` Poczatek, Jakub
2022-06-22 15:31             ` David Marchand
2022-05-20 20:13 ` [PATCH 00/12] Fix compilation with gcc 12 Stephen Hemminger
2022-05-21  9:39   ` Morten Brørup
2022-06-15  8:49 ` David Marchand
2022-06-15 14:45   ` Stephen Hemminger
2022-06-15 14:59     ` Thomas Monjalon
2022-06-15 15:15       ` Stephen Hemminger

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=1f0bee5c-56c5-11f1-5452-5aa6c00d2acc@intel.com \
    --to=vladimir.medvedkin@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@xilinx.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.