From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH] crypto/aesni_mb: fix assert check
Date: Wed, 31 May 2017 15:52:14 -0700
Message-ID: <20170531155214.3758e616@xeon-e3>
References: <20170531134443.39911-1-pablo.de.lara.guarch@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: declan.doherty@intel.com, dev@dpdk.org, stable@dpdk.org
To: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com
 [209.85.192.180]) by dpdk.org (Postfix) with ESMTP id 2886C7CA9
 for <dev@dpdk.org>; Thu,  1 Jun 2017 00:52:23 +0200 (CEST)
Received: by mail-pf0-f180.google.com with SMTP id e193so19863419pfh.0
 for <dev@dpdk.org>; Wed, 31 May 2017 15:52:23 -0700 (PDT)
In-Reply-To: <20170531134443.39911-1-pablo.de.lara.guarch@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Wed, 31 May 2017 14:44:43 +0100
Pablo de Lara <pablo.de.lara.guarch@intel.com> wrote:

> Fixes: 0f548b50a160 ("crypto/aesni_mb: process crypto op on dequeue")
> CC: stable@dpdk.org
> 
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> ---
>  drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> index 45b25c9..dde60c0 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c
> @@ -494,7 +494,7 @@ static inline void
>  verify_digest(JOB_AES_HMAC *job, struct rte_crypto_op *op) {
>  	struct rte_mbuf *m_dst = (struct rte_mbuf *)job->user_data2;
>  
> -	RTE_ASSERT(m_dst == NULL);
> +	RTE_ASSERT(m_dst != NULL);
>  
>  	/* Verify digest if required */
>  	if (memcmp(job->auth_tag_output, op->sym->auth.digest.data,
> @@ -522,7 +522,7 @@ post_process_mb_job(struct aesni_mb_qp *qp, JOB_AES_HMAC *job)
>  
>  	struct aesni_mb_session *sess;
>  
> -	RTE_ASSERT(op == NULL);
> +	RTE_ASSERT(op != NULL);
>  
>  	if (unlikely(op->status == RTE_CRYPTO_OP_STATUS_ENQUEUED)) {
>  		switch (job->status) {

These kind of asserts are actually meaningless. In real world,
it really doesn't matter if application panics because of assert (sigabort) or
because of segfault on null pointer dereference. In either case it causes
a crash. If you have built in a real signal handler and  backtracing, or
enabled core dumps then data is available. If not then the application just
dies.