From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 3961842B77;
	Mon, 22 May 2023 23:25:15 +0200 (CEST)
Received: from mails.dpdk.org (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id C1BD540A79;
	Mon, 22 May 2023 23:25:14 +0200 (CEST)
Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com
 [209.85.210.181])
 by mails.dpdk.org (Postfix) with ESMTP id 249DE400D5
 for <dev@dpdk.org>; Mon, 22 May 2023 23:25:14 +0200 (CEST)
Received: by mail-pf1-f181.google.com with SMTP id
 d2e1a72fcca58-64d2c865e4eso3283498b3a.0
 for <dev@dpdk.org>; Mon, 22 May 2023 14:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1684790713;
 x=1687382713; 
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:from:to:cc:subject:date
 :message-id:reply-to;
 bh=D8Zmxb1sDH2iPNNVPz81OellzlUdej0nHeA7EjBTdRE=;
 b=oaJ0nQWJw9imTfev3xy11Meg0V/SPkcj6/lgMwndmeG+CNj/7l5lDdf/fv49/XWYVN
 iXE+TEbwc5HbRupclb84LTDcx74305EuTWqrosL3XSCRWVJtSBQZBSUs9wdoytXeuFn1
 Rt6HAXVtbaomIUSgeBstzuGZmbSilt9MUMoOuEYt5vxPtZxC9lIJMPjQ3wDLaX142liW
 bPm0g106Cs9a0WFxiCU6hBEg/RSZDT67dpLI6BNMFS0Q5ApBW7OI2wyipHF7c9okr8pR
 ytormA3me3V0cGCrOj4/IL+Xf2QrvYdjvI1t6HkOE+kJ3Whz3uKy5rpwAkGCiY1oUT8k
 sIIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1684790713; x=1687382713;
 h=content-transfer-encoding:mime-version:references:in-reply-to
 :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc
 :subject:date:message-id:reply-to;
 bh=D8Zmxb1sDH2iPNNVPz81OellzlUdej0nHeA7EjBTdRE=;
 b=a1tmN9p8LlgG9uHpImH436A85XCxwlgspPwYfhyZAaqEQTuGh3wkIBmuH7Ylu9RFLm
 /P8u11n8BsBYGMb1D1v2oTjqiOZHbtSB5499VjsSrtaz7DymfDk/3im9CXXTQaT9DOkM
 pFIJQVlStz5mNad8IsH0kX3sKTwkXvW0YHQbjMds7VgnZiCk5BAFjsz+3bRquKGkKtsT
 UQyvgTCd+pHNZUVeEgaX+koLIzVpMdY7GllyOb0SvCWC6dHq5TtH/cz30AIWCyWc12gb
 /xJfxWYwMhJM+Ni/tHyHmbUEFrHxaIObQ9MJWFscWObkypfWXUWvnEUyn7ArQ5zDgWwY
 h1ag==
X-Gm-Message-State: AC+VfDx+SK9R3+wAZErNtcHVtzv6yrcOZkrhJz6Ip0DS1vI23NSFvE0t
 3OZfH37EwyPBRacP/i3Qh9+Q9A==
X-Google-Smtp-Source: ACHHUZ6+8YrVzoK5dnHpTBWf1xlxXy1LDtUejATdWU56cO1ZryRnMXCaHLxb7zylymW1OgNgQlpJMA==
X-Received: by 2002:a05:6a00:24d4:b0:64d:2c61:4b1 with SMTP id
 d20-20020a056a0024d400b0064d2c6104b1mr15480921pfv.11.1684790713100; 
 Mon, 22 May 2023 14:25:13 -0700 (PDT)
Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218])
 by smtp.gmail.com with ESMTPSA id
 j8-20020aa783c8000000b00640f01e130fsm4493846pfn.124.2023.05.22.14.25.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 22 May 2023 14:25:12 -0700 (PDT)
Date: Mon, 22 May 2023 14:25:10 -0700
From: Stephen Hemminger <stephen@networkplumber.org>
To: Kamil Godzwon <kamilx.godzwon@intel.com>
Cc: dev@dpdk.org, Akhil Goyal <gakhil@marvell.com>, Fan Zhang
 <fanzhang.oss@gmail.com>
Subject: Re: [PATCH v2] lib/cryptodev: fix assertion to remove GCC
 compilation warning
Message-ID: <20230522142510.3952adc5@hermes.local>
In-Reply-To: <20230522190453.453281-1-kamilx.godzwon@intel.com>
References: <20230522184951.452626-1-kamilx.godzwon@intel.com>
 <20230522190453.453281-1-kamilx.godzwon@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org

On Mon, 22 May 2023 15:04:52 -0400
Kamil Godzwon <kamilx.godzwon@intel.com> wrote:

> /home/vagrant/dpdk/build/include/rte_crypto_sym.h:1009:4: \
> warning: Value stored to 'left' is never read [deadcode.DeadStores]
>                           left = 0;
>                           ^      ~
>   1 warning generated.
> 
> Compilator sees that the variable 'left' is never read after
> assignment a '0' value. To get rid of this warning message, use 'if'
> condition to verify the 'left' value before RTE_ASSERT.
> 
> Signed-off-by: Kamil Godzwon <kamilx.godzwon@intel.com>
> ---
> v2:
> Changed commit message as the line was too long
> Removed braces
> ---
>  lib/cryptodev/rte_crypto_sym.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
> index b43174dbec..dcef1a5049 100644
> --- a/lib/cryptodev/rte_crypto_sym.h
> +++ b/lib/cryptodev/rte_crypto_sym.h
> @@ -1016,7 +1016,9 @@ rte_crypto_mbuf_to_vec(const struct rte_mbuf *mb, uint32_t ofs, uint32_t len,
>  		left -= seglen;
>  	}
>  
> -	RTE_ASSERT(left == 0);
> +	if (left != 0)
> +		RTE_ASSERT(false);
> +
>  	return i;
>  }
>  

This could happen if the passed in length to this routine was larger than
the amount of data in the mbuf. Should the function check and return an error?

Panic should only be reserved for seriously corrupted input (like invalid mbuf).

Also, this is a big enough function that it really should not be inlined.