From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v2] cryptodev: fix NULL pointer dereference
Date: Tue, 01 Aug 2017 11:35:27 +0200
Message-ID: <5207907.Bg9B3aH5F5@xps>
References: <20170731023050.28956-1-pablo.de.lara.guarch@intel.com>
 <7230298.g0yYOUbsxP@xps> <ec4bd956-e079-8d0b-4ab2-41f6ec1b0ce5@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: Pablo de Lara <pablo.de.lara.guarch@intel.com>, dev@dpdk.org
To: Sergio Gonzalez Monroy <sergio.gonzalez.monroy@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0B3E09B7D
 for <dev@dpdk.org>; Tue,  1 Aug 2017 11:35:28 +0200 (CEST)
In-Reply-To: <ec4bd956-e079-8d0b-4ab2-41f6ec1b0ce5@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>

01/08/2017 10:13, Sergio Gonzalez Monroy:
> On 31/07/2017 20:33, Thomas Monjalon wrote:
> > 31/07/2017 11:18, Pablo de Lara:
> >> When register a crypto driver, a cryptodev driver
> >> structure was being allocated, using malloc.
> >> Since this call may fail, it is safer to allocate
> >> this memory statically in each PMD, so driver registration
> >> will never fail.
> >>
> >> Coverity issue: 158645
> >>
> >> Fixes: 7a364faef185 ("cryptodev: remove crypto device type enumeration")
> >>
> >> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
> >> ---
> >>
> >> Changes in v2:
> >>
> >> - Allocate statically the cryptodev driver structure,
> >>    instead of using malloc, that can potentially fail.
> >>
> >>   drivers/crypto/aesni_gcm/aesni_gcm_pmd.c    |  5 ++++-
> >>   drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c  |  6 +++++-
> >>   drivers/crypto/armv8/rte_armv8_pmd.c        |  9 ++++++---
> >>   drivers/crypto/dpaa2_sec/dpaa2_sec_dpseci.c |  5 ++++-
> >>   drivers/crypto/kasumi/rte_kasumi_pmd.c      |  5 ++++-
> >>   drivers/crypto/null/null_crypto_pmd.c       |  5 ++++-
> >>   drivers/crypto/openssl/rte_openssl_pmd.c    |  5 ++++-
> >>   drivers/crypto/qat/rte_qat_cryptodev.c      |  7 +++++--
> >>   drivers/crypto/scheduler/scheduler_pmd.c    |  5 ++++-
> >>   drivers/crypto/snow3g/rte_snow3g_pmd.c      |  5 ++++-
> >>   drivers/crypto/zuc/rte_zuc_pmd.c            |  5 ++++-
> >>   lib/librte_cryptodev/rte_cryptodev.c        | 18 +++++------------
> >>   lib/librte_cryptodev/rte_cryptodev.h        | 20 -------------------
> >>   lib/librte_cryptodev/rte_cryptodev_pmd.h    | 30 +++++++++++++++++++++++++++++
> >>   14 files changed, 83 insertions(+), 47 deletions(-)
> > This is a big change for a small/unlikely issue.
> > The main benefit of this patch is an allocation cleanup.
> > I think it is better to wait 17.11 cycle to integrate it.
> 
> We initially thought of exit given that it is a constructor and if you 
> fail to allocate memory at this stage, things are likely not going to 
> work out anyway.

You don't know how the application wants to manage it.

> The patch is an API change, do we really want to break again (we are 
> breaking in this release) next release?

Good question. Any opinions?