From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id A8A3D37B4; Wed, 21 Jun 2017 16:20:38 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP; 21 Jun 2017 07:20:37 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,369,1493708400"; d="scan'208";a="870290511" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by FMSMGA003.fm.intel.com with ESMTP; 21 Jun 2017 07:20:36 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.133]) by IRSMSX152.ger.corp.intel.com ([169.254.6.83]) with mapi id 14.03.0319.002; Wed, 21 Jun 2017 15:20:35 +0100 From: "De Lara Guarch, Pablo" To: Stephen Hemminger CC: "Doherty, Declan" , "dev@dpdk.org" , "stable@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] crypto/aesni_mb: fix assert check Thread-Index: AQHS2lccfnZoFHPvN0qaB30BbnQi7KIO+6UAgCCCmUA= Date: Wed, 21 Jun 2017 14:20:35 +0000 Message-ID: References: <20170531134443.39911-1-pablo.de.lara.guarch@intel.com> <20170531155214.3758e616@xeon-e3> In-Reply-To: <20170531155214.3758e616@xeon-e3> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] crypto/aesni_mb: fix assert check X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:20:40 -0000 Hi Stephen, > -----Original Message----- > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Wednesday, May 31, 2017 11:52 PM > To: De Lara Guarch, Pablo > Cc: Doherty, Declan ; dev@dpdk.org; > stable@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] crypto/aesni_mb: fix assert check >=20 > On Wed, 31 May 2017 14:44:43 +0100 > Pablo de Lara wrote: >=20 > > Fixes: 0f548b50a160 ("crypto/aesni_mb: process crypto op on dequeue") > > CC: stable@dpdk.org > > > > Signed-off-by: Pablo de Lara > > --- > > 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 =3D (struct rte_mbuf *)job->user_data2; > > > > - RTE_ASSERT(m_dst =3D=3D NULL); > > + RTE_ASSERT(m_dst !=3D 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 =3D=3D NULL); > > + RTE_ASSERT(op !=3D NULL); > > > > if (unlikely(op->status =3D=3D RTE_CRYPTO_OP_STATUS_ENQUEUED)) { > > switch (job->status) { >=20 > 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 s= egfault > on null pointer dereference. In either case it causes a crash. If you hav= e 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.