From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <stable-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id D8164A054F
for <public@inbox.dpdk.org>; Thu, 2 Jun 2022 11:50:44 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id C807540E09;
Thu, 2 Jun 2022 11:50:44 +0200 (CEST)
Received: from mga04.intel.com (mga04.intel.com [192.55.52.120])
by mails.dpdk.org (Postfix) with ESMTP id D174A4021E;
Thu, 2 Jun 2022 11:50:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1654163442; x=1685699442;
h=date:from:to:cc:subject:message-id:references:
mime-version:content-transfer-encoding:in-reply-to;
bh=PSNev9bUKXwVtwVt+Atoz85JbErVcW7LkDHl8E8Grao=;
b=cQGbonE4uJlWxCqPCYRuA22bd8iVj58Q+UQFhqbgQvy/kx4riXeCf440
S8A8CNFFKOBofO0phriwAR4NRNxlvLEudI/zpCTtN9xASwfOD2Gv/nR72
//63iqzDnIMRRzP0JUQpfe+vB34ZJp4zN7hob6ZyOque6EknzVAM+fTm+
6ZExtxVK8tthk+yGvuFTZ51hSAbZpey+XKrB5OjHg2iCMYDh4YH+dyJRj
83Z/jDHfaDLYMtCdEvWZYSiNc4t3MXqvadlHmavLiR3pDGYjbboK6Sm9V
m7r21ne+jgHTvg7pNCpThM1We0Zp2o7oT/3wT9qGrd+a5Cr70C5JKF/vu g==;
X-IronPort-AV: E=McAfee;i="6400,9594,10365"; a="274698414"
X-IronPort-AV: E=Sophos;i="5.91,270,1647327600"; d="scan'208";a="274698414"
Received: from fmsmga005.fm.intel.com ([10.253.24.32])
by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
02 Jun 2022 02:50:40 -0700
X-IronPort-AV: E=Sophos;i="5.91,270,1647327600"; d="scan'208";a="904907972"
Received: from bricha3-mobl.ger.corp.intel.com ([10.55.133.25])
by fmsmga005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA;
02 Jun 2022 02:50:39 -0700
Date: Thu, 2 Jun 2022 10:50:36 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, thomas@monjalon.net, ferruh.yigit@xilinx.com,
stable@dpdk.org, Fan Zhang <roy.fan.zhang@intel.com>,
Pablo de Lara <pablo.de.lara.guarch@intel.com>,
Deepak Kumar Jain <deepak.k.jain@intel.com>
Subject: Re: [PATCH 03/12] crypto/ipsec_mb: fix build with GCC 12
Message-ID: <YpiH7C/8xWgajyzw@bricha3-MOBL.ger.corp.intel.com>
References: <20220518101657.1230416-1-david.marchand@redhat.com>
<20220518101657.1230416-4-david.marchand@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220518101657.1230416-4-david.marchand@redhat.com>
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/stable>,
<mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/stable>,
<mailto:stable-request@dpdk.org?subject=subscribe>
Errors-To: stable-bounces@dpdk.org
On Wed, May 18, 2022 at 12:16:48PM +0200, David Marchand wrote:
> GCC 12 raises the following warning:
>
> In function ‘__rte_ring_enqueue_elems_64’,
> inlined from ‘__rte_ring_enqueue_elems’ at
> ../lib/ring/rte_ring_elem_pvt.h:130:3,
> inlined from ‘__rte_ring_do_hts_enqueue_elem’ at
> ../lib/ring/rte_ring_hts_elem_pvt.h:196:3,
> inlined from ‘rte_ring_mp_hts_enqueue_burst_elem’ at
> ../lib/ring/rte_ring_hts.h:110:9,
> inlined from ‘rte_ring_enqueue_burst_elem’ at
> ../lib/ring/rte_ring_elem.h:577:10,
> inlined from ‘rte_ring_enqueue_burst’ at
> ../lib/ring/rte_ring.h:738:9,
> inlined from ‘process_op_bit’ at
> ../drivers/crypto/ipsec_mb/pmd_snow3g.c:425:16,
> inlined from ‘snow3g_pmd_dequeue_burst’ at
> ../drivers/crypto/ipsec_mb/pmd_snow3g.c:484:20:
> ../lib/ring/rte_ring_elem_pvt.h:68:44: error: array subscript 1 is
> outside array bounds of ‘struct rte_crypto_op[0]’
> [-Werror=array-bounds]
> 68 | ring[idx + 1] = obj[i + 1];
> | ~~~^~~~~~~
> ../drivers/crypto/ipsec_mb/pmd_snow3g.c: In function
> ‘snow3g_pmd_dequeue_burst’:
> ../drivers/crypto/ipsec_mb/pmd_snow3g.c:434:1: note:
> at offset 8 into object ‘op’ of size 8
> 434 | snow3g_pmd_dequeue_burst(void *queue_pair,
> | ^~~~~~~~~~~~~~~~~~~~~~~~
>
> Validate that one (exactly) op has been processed or return early.
>
> Fixes: b537abdbee74 ("crypto/snow3g: support bit-level operations")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> drivers/crypto/ipsec_mb/pmd_snow3g.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/crypto/ipsec_mb/pmd_snow3g.c b/drivers/crypto/ipsec_mb/pmd_snow3g.c
> index ebc9a0b562..9a85f46721 100644
> --- a/drivers/crypto/ipsec_mb/pmd_snow3g.c
> +++ b/drivers/crypto/ipsec_mb/pmd_snow3g.c
> @@ -422,12 +422,13 @@ process_op_bit(struct rte_crypto_op *op, struct snow3g_session *session,
> op->sym->session = NULL;
> }
>
> - enqueued_op = rte_ring_enqueue_burst(qp->ingress_queue,
> - (void **)&op, processed_op, NULL);
> + if (unlikely(processed_op != 1))
> + return 0;
> + enqueued_op = rte_ring_enqueue(qp->ingress_queue, op);
As a fix for the compiler warning this looks ok, but question for
maintainer would be - should this check for processed_op != 1 not go
earlier in the function, immediately after the switch statement?
Fan, Pablo, can you please comment?
/Bruce