Hi Stephen,

-----Original Message-----
From: Stephen Hemminger [mailto:stephen@networkplumber.org]
Sent: Wednesday, May 31, 2017 11:52 PM
To: De Lara Guarch, Pablo <redacted>
Cc: Doherty, Declan <redacted>; dev@dpdk.org;
stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] crypto/aesni_mb: fix assert check

On Wed, 31 May 2017 14:44:43 +0100
Pablo de Lara [off-list ref] wrote:

quoted

Fixes: 0f548b50a160 ("crypto/aesni_mb: process crypto op on dequeue")
CC: stable@dpdk.org

Signed-off-by: Pablo de Lara <redacted>
---
 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.

Good point, I will remove it then.