From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 83C8CA0559; Fri, 3 Jun 2022 11:41:46 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DBEF442905; Fri, 3 Jun 2022 11:41:45 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 3952F40694 for ; Fri, 3 Jun 2022 11:41:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1654249303; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vyGE6o3nGgTv5V0VTTEbRzIkL5r6LtTeo9Tvg/qYxQ0=; b=BSqbp9egS04kZjpTJaQ05eDBX3MALkYDamabaIEET5H6TVP5IHv+bcdBcTs74fDwDJWn0r Cc7RK9Kjs6628TAlzgEWvI7Qgbo6vrOZGQWsTrdCfn5Vc+CPOoslQN/YWm+ayWQfx6Ipox GK8BaShz7fBkl58yCG+C/EBB+BKKfCE= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-529-97Y6-sVWNIqC18FXEu_cUA-1; Fri, 03 Jun 2022 05:41:42 -0400 X-MC-Unique: 97Y6-sVWNIqC18FXEu_cUA-1 Received: by mail-lj1-f199.google.com with SMTP id e22-20020a2e9e16000000b00253cd8911easo1178031ljk.13 for ; Fri, 03 Jun 2022 02:41:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vyGE6o3nGgTv5V0VTTEbRzIkL5r6LtTeo9Tvg/qYxQ0=; b=B+ptew4YI0UXGEAJUc551UbpEFx624gzi+v+NNUYtniPHfQkmYb/pBTt0uD+9udJD4 bFk2zjkVxDhk/a62o3Y/hPAJ+9DAGJ3RDQDyA2CLfFhXZN9JLpQFJOBiEi7dPL3gxFyQ fTGVWmSWFGr87Vat0SXJ4EOA/CMiHtZDzDbsGds/UhVjn1W5boHGseIlNCRTkBll/lwJ 0NZGxS/FODhPFYqETRDef13OX0eb6PYzlWfnBObQlb3NuGG3fjnSa3eXL19Zw7dCr1Lg kY0B2TqpjzXanyN7STX1PZrkrhQXtViaBymZVK8Zpnws7H/INfsvJC4C9BTeah2uKL14 5GOQ== X-Gm-Message-State: AOAM531/WSoEqtqC1b8srXQVOrKEAgcu30n6cHQ+BA6xMj9UWeabYYab EDy9T93T5yJmI2ip9tmUH7ggHSjOlrzRBVsGE3aqc/EK7gG8+7E49FUIJu3cjawsKDB+jKYP7qy UW8CCWYZfdWwXZCLLTBs= X-Received: by 2002:a05:6512:259f:b0:477:bbc5:182c with SMTP id bf31-20020a056512259f00b00477bbc5182cmr32199469lfb.265.1654249301197; Fri, 03 Jun 2022 02:41:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwAFeAIyn5DXZGZMM10SaEh2FLoHREY6xj1L7VgqhcGiJXS2Enqd8HR/xkNtNAyGXq0Xu7hozRytlbGHgymK9k= X-Received: by 2002:a05:6512:259f:b0:477:bbc5:182c with SMTP id bf31-20020a056512259f00b00477bbc5182cmr32199451lfb.265.1654249300873; Fri, 03 Jun 2022 02:41:40 -0700 (PDT) MIME-Version: 1.0 References: <20220518101657.1230416-1-david.marchand@redhat.com> <20220518101657.1230416-13-david.marchand@redhat.com> In-Reply-To: From: David Marchand Date: Fri, 3 Jun 2022 11:41:29 +0200 Message-ID: Subject: Re: [PATCH 12/12] test/ipsec: fix build with GCC 12 To: Bruce Richardson Cc: "Medvedkin, Vladimir" , dev , Thomas Monjalon , Ferruh Yigit , dpdk stable , Konstantin Ananyev , Bernard Iremonger Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmarchan@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Jun 3, 2022 at 9:56 AM Bruce Richardson 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 > > 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. > > > 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); + if (m) { memset(m->buf_addr, 0, m->buf_len); -- David Marchand