From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0B3E09B7D for ; Tue, 1 Aug 2017 11:35:28 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 818CB2088E; Tue, 1 Aug 2017 05:35:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 01 Aug 2017 05:35:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=+jwdQtWc9tXN/+t N6yjX0OuWwNoLDcjuQSoWpdMjIY8=; b=k56yluVXJ1MLto85AijR24luyVz5AZS 3skrRDVLaBbwTBNYQIDpGkvQ+eqAW7cuo84s+DVbsAjriRa+75KA/hBr6blfc/ja N7a452iOy7g+7e5/UVIMaCbrzHpA66ODg0h3Z1BeTORFoZGAqrOh+9Pqf27IzSRO z0d7SszIPuzE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=+jwdQtWc9tXN/+tN6yjX0OuWwNoLDcjuQSoWpdMjIY8=; b=i7M4gynr jhuY89PkGVlWm/8l4B8ZaArSgDh6nHVkAaHkTBxbgfiLkmiNInzzHk9RObxJeobk d3K8L3n12Vq00bFTMV9LAIFWq/cQaUtLsGz1IC/RI013fvUM2rnGFx67wRpENBtH 1O8mJD5hWRjfAj1UNRYYCDpIZ6UIUYGNu7HOzJaIxOtO6NUBk051c/E9f/+UymkS tvjvFdZAGiib6ktXF44VVqK8q4JyM5h0z76J/5r2S+b4YJFcEil7JIOwE1TNVNl/ FVf1qiKwNFNsdbgp76f31wl89c3IHEyPCwNQrAUTrWbLdLDTfAcJofMWnd5llBjH o8WyDhDePsH3PQ== X-ME-Sender: X-Sasl-enc: vK8cCUp2nZeTF5CWrKrmGOrPZkJyge2eow4Hl5r01SZA 1501580128 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 05E6A2486D; Tue, 1 Aug 2017 05:35:28 -0400 (EDT) From: Thomas Monjalon To: Sergio Gonzalez Monroy Cc: Pablo de Lara , dev@dpdk.org Date: Tue, 01 Aug 2017 11:35:27 +0200 Message-ID: <5207907.Bg9B3aH5F5@xps> In-Reply-To: References: <20170731023050.28956-1-pablo.de.lara.guarch@intel.com> <7230298.g0yYOUbsxP@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] cryptodev: fix NULL pointer dereference 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: Tue, 01 Aug 2017 09:35:29 -0000 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 > >> --- > >> > >> 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?