Hi Stephen, > -----Original Message----- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Wednesday, May 31, 2017 11:52 PM > To: De Lara Guarch, Pablo <pablo.de.lara.gua...@intel.com> > Cc: Doherty, Declan <declan.dohe...@intel.com>; dev@dpdk.org; > sta...@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 <pablo.de.lara.gua...@intel.com> wrote: > > > Fixes: 0f548b50a160 ("crypto/aesni_mb: process crypto op on dequeue") > > CC: sta...@dpdk.org > > > > Signed-off-by: Pablo de Lara <pablo.de.lara.gua...@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.
Good point, I will remove it then.