DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Cc: declan.doherty@intel.com, dev@dpdk.org, stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] crypto/aesni_mb: fix assert check
Date: Wed, 31 May 2017 15:52:14 -0700	[thread overview]
Message-ID: <20170531155214.3758e616@xeon-e3> (raw)
In-Reply-To: <20170531134443.39911-1-pablo.de.lara.guarch@intel.com>

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.

  reply	other threads:[~2017-05-31 22:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-31 13:44 Pablo de Lara
2017-05-31 22:52 ` Stephen Hemminger [this message]
2017-06-21 14:20   ` De Lara Guarch, Pablo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170531155214.3758e616@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=stable@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).