[dpdk-dev,v2] cryptodev: fix NULL pointer dereference
Checks
Commit Message
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(-)
Comments
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.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Monday, July 31, 2017 8:33 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] cryptodev: fix NULL pointer dereference
>
> 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.
Makes sense, Thomas.
Thanks,
Pablo
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.
The patch is an API change, do we really want to break again (we are
breaking in this release) next release?
Thanks,
Sergio
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?
On 01/08/2017 10:35, Thomas Monjalon wrote:
> 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.
IMHO setting an internal variable indicating an error in constructors
and then reporting the problem during EAL init seems overly complex.
I think the proposed change is a cleaner solution.
>> 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?
Merge the patch unless there are already outstanding and/or planned
changes for the next release that are going to break ABI/API?
Thanks,
Sergio
> -----Original Message-----
> From: Gonzalez Monroy, Sergio
> Sent: Tuesday, August 1, 2017 11:18 AM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>;
> dev@dpdk.org
> Subject: Re: [PATCH v2] cryptodev: fix NULL pointer dereference
>
> On 01/08/2017 10:35, Thomas Monjalon wrote:
> > 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.
>
> IMHO setting an internal variable indicating an error in constructors and
> then reporting the problem during EAL init seems overly complex.
> I think the proposed change is a cleaner solution.
>
> >> 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?
>
> Merge the patch unless there are already outstanding and/or planned
> changes for the next release that are going to break ABI/API?
There is another patchset that was postponed for next release, because the
compilation was broken in one of the patches (just double checked and it is easy to fix),
and by then, I thought that no ABI/API was being broken,
but it will be (my bad here). This is the patchset I am talking about:
[PATCH v2 0/4] cryptodev vdev changes for -rc2
http://dpdk.org/ml/archives/dev/2017-July/071160.html
So we have two options here:
1 - Get both patches now, since we are breaking the ABI in this release (as Sergio pointed out).
2 - Postpone both changes to next release.
I would go for option 1, as there are no other changes expected for next release
(only one function, rte_cryptodev_create_vdev, will be removed).
Thanks,
Pablo
>
>
> Thanks,
> Sergio
01/08/2017 12:48, De Lara Guarch, Pablo:
> From: Gonzalez Monroy, Sergio
> > On 01/08/2017 10:35, Thomas Monjalon wrote:
> > > 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.
> >
> > IMHO setting an internal variable indicating an error in constructors and
> > then reporting the problem during EAL init seems overly complex.
> > I think the proposed change is a cleaner solution.
> >
> > >> 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?
> >
> > Merge the patch unless there are already outstanding and/or planned
> > changes for the next release that are going to break ABI/API?
>
> There is another patchset that was postponed for next release, because the
> compilation was broken in one of the patches (just double checked and it is easy to fix),
> and by then, I thought that no ABI/API was being broken,
> but it will be (my bad here). This is the patchset I am talking about:
>
> [PATCH v2 0/4] cryptodev vdev changes for -rc2
> http://dpdk.org/ml/archives/dev/2017-July/071160.html
>
> So we have two options here:
> 1 - Get both patches now, since we are breaking the ABI in this release (as Sergio pointed out).
> 2 - Postpone both changes to next release.
>
> I would go for option 1, as there are no other changes expected for next release
> (only one function, rte_cryptodev_create_vdev, will be removed).
Given that there is a new release every 3 months, I prefer the safe way.
Anyway, if a function is going to be removed, the API and ABI will change.
@@ -630,10 +630,13 @@ static struct rte_vdev_driver aesni_gcm_pmd_drv = {
.remove = aesni_gcm_remove
};
+static struct cryptodev_driver aesni_gcm_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_AESNI_GCM_PMD, aesni_gcm_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_AESNI_GCM_PMD, cryptodev_aesni_gcm_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_AESNI_GCM_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(aesni_gcm_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(aesni_gcm_crypto_drv, aesni_gcm_pmd_drv,
+ cryptodev_driver_id);
@@ -823,10 +823,14 @@ static struct rte_vdev_driver cryptodev_aesni_mb_pmd_drv = {
.remove = cryptodev_aesni_mb_remove
};
+static struct cryptodev_driver aesni_mb_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_AESNI_MB_PMD, cryptodev_aesni_mb_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_AESNI_MB_PMD, cryptodev_aesni_mb_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_AESNI_MB_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_aesni_mb_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(aesni_mb_crypto_drv,
+ cryptodev_aesni_mb_pmd_drv,
+ cryptodev_driver_id);
@@ -908,15 +908,18 @@ cryptodev_armv8_crypto_uninit(struct rte_vdev_device *vdev)
return 0;
}
-static struct rte_vdev_driver armv8_crypto_drv = {
+static struct rte_vdev_driver armv8_crypto_pmd_drv = {
.probe = cryptodev_armv8_crypto_init,
.remove = cryptodev_armv8_crypto_uninit
};
-RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_ARMV8_PMD, armv8_crypto_drv);
+static struct cryptodev_driver armv8_crypto_drv;
+
+RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_ARMV8_PMD, armv8_crypto_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_ARMV8_PMD, cryptodev_armv8_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_ARMV8_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(armv8_crypto_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(armv8_crypto_drv, armv8_crypto_pmd_drv,
+ cryptodev_driver_id);
@@ -2008,5 +2008,8 @@ static struct rte_dpaa2_driver rte_dpaa2_sec_driver = {
.remove = cryptodev_dpaa2_sec_remove,
};
+static struct cryptodev_driver dpaa2_sec_crypto_drv;
+
RTE_PMD_REGISTER_DPAA2(CRYPTODEV_NAME_DPAA2_SEC_PMD, rte_dpaa2_sec_driver);
-RTE_PMD_REGISTER_CRYPTO_DRIVER(rte_dpaa2_sec_driver, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(dpaa2_sec_crypto_drv, rte_dpaa2_sec_driver,
+ cryptodev_driver_id);
@@ -661,10 +661,13 @@ static struct rte_vdev_driver cryptodev_kasumi_pmd_drv = {
.remove = cryptodev_kasumi_remove
};
+static struct cryptodev_driver kasumi_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_KASUMI_PMD, cryptodev_kasumi_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_KASUMI_PMD, cryptodev_kasumi_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_KASUMI_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_kasumi_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(kasumi_crypto_drv, cryptodev_kasumi_pmd_drv,
+ cryptodev_driver_id);
@@ -286,10 +286,13 @@ static struct rte_vdev_driver cryptodev_null_pmd_drv = {
.remove = cryptodev_null_remove_dev,
};
+static struct cryptodev_driver null_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_NULL_PMD, cryptodev_null_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_NULL_PMD, cryptodev_null_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_NULL_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_null_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(null_crypto_drv, cryptodev_null_pmd_drv,
+ cryptodev_driver_id);
@@ -1502,10 +1502,13 @@ static struct rte_vdev_driver cryptodev_openssl_pmd_drv = {
.remove = cryptodev_openssl_remove
};
+static struct cryptodev_driver openssl_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_OPENSSL_PMD,
cryptodev_openssl_pmd_drv);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_OPENSSL_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_openssl_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(openssl_crypto_drv, cryptodev_openssl_pmd_drv,
+ cryptodev_driver_id);
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2015-2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2015-2017 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -169,6 +169,9 @@ static struct rte_pci_driver rte_qat_pmd = {
.remove = crypto_qat_pci_remove
};
+static struct cryptodev_driver qat_crypto_drv;
+
RTE_PMD_REGISTER_PCI(CRYPTODEV_NAME_QAT_SYM_PMD, rte_qat_pmd);
RTE_PMD_REGISTER_PCI_TABLE(CRYPTODEV_NAME_QAT_SYM_PMD, pci_id_qat_map);
-RTE_PMD_REGISTER_CRYPTO_DRIVER(rte_qat_pmd, cryptodev_qat_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(qat_crypto_drv, rte_qat_pmd,
+ cryptodev_qat_driver_id);
@@ -505,6 +505,8 @@ static struct rte_vdev_driver cryptodev_scheduler_pmd_drv = {
.remove = cryptodev_scheduler_remove
};
+static struct cryptodev_driver scheduler_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_SCHEDULER_PMD,
cryptodev_scheduler_pmd_drv);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_SCHEDULER_PMD,
@@ -512,5 +514,6 @@ RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_SCHEDULER_PMD,
"max_nb_sessions=<int> "
"socket_id=<int> "
"slave=<name>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_scheduler_pmd_drv,
+RTE_PMD_REGISTER_CRYPTO_DRIVER(scheduler_crypto_drv,
+ cryptodev_scheduler_pmd_drv,
cryptodev_driver_id);
@@ -661,10 +661,13 @@ static struct rte_vdev_driver cryptodev_snow3g_pmd_drv = {
.remove = cryptodev_snow3g_remove
};
+static struct cryptodev_driver snow3g_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_SNOW3G_PMD, cryptodev_snow3g_pmd_drv);
RTE_PMD_REGISTER_ALIAS(CRYPTODEV_NAME_SNOW3G_PMD, cryptodev_snow3g_pmd);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_SNOW3G_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_snow3g_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(snow3g_crypto_drv, cryptodev_snow3g_pmd_drv,
+ cryptodev_driver_id);
@@ -565,9 +565,12 @@ static struct rte_vdev_driver cryptodev_zuc_pmd_drv = {
.remove = cryptodev_zuc_remove
};
+static struct cryptodev_driver zuc_crypto_drv;
+
RTE_PMD_REGISTER_VDEV(CRYPTODEV_NAME_ZUC_PMD, cryptodev_zuc_pmd_drv);
RTE_PMD_REGISTER_PARAM_STRING(CRYPTODEV_NAME_ZUC_PMD,
"max_nb_queue_pairs=<int> "
"max_nb_sessions=<int> "
"socket_id=<int>");
-RTE_PMD_REGISTER_CRYPTO_DRIVER(cryptodev_zuc_pmd_drv, cryptodev_driver_id);
+RTE_PMD_REGISTER_CRYPTO_DRIVER(zuc_crypto_drv, cryptodev_zuc_pmd_drv,
+ cryptodev_driver_id);
@@ -1362,12 +1362,6 @@ TAILQ_HEAD(cryptodev_driver_list, cryptodev_driver);
static struct cryptodev_driver_list cryptodev_driver_list =
TAILQ_HEAD_INITIALIZER(cryptodev_driver_list);
-struct cryptodev_driver {
- TAILQ_ENTRY(cryptodev_driver) next; /**< Next in list. */
- const struct rte_driver *driver;
- uint8_t id;
-};
-
int
rte_cryptodev_driver_id_get(const char *name)
{
@@ -1399,15 +1393,13 @@ rte_cryptodev_driver_name_get(uint8_t driver_id)
}
uint8_t
-rte_cryptodev_allocate_driver(const struct rte_driver *drv)
+rte_cryptodev_allocate_driver(struct cryptodev_driver *crypto_drv,
+ const struct rte_driver *drv)
{
- struct cryptodev_driver *driver;
-
- driver = malloc(sizeof(*driver));
- driver->driver = drv;
- driver->id = nb_drivers;
+ crypto_drv->driver = drv;
+ crypto_drv->id = nb_drivers;
- TAILQ_INSERT_TAIL(&cryptodev_driver_list, driver, next);
+ TAILQ_INSERT_TAIL(&cryptodev_driver_list, crypto_drv, next);
return nb_drivers++;
}
@@ -1025,26 +1025,6 @@ int rte_cryptodev_driver_id_get(const char *name);
*/
const char *rte_cryptodev_driver_name_get(uint8_t driver_id);
-/**
- * @internal
- * Allocate Cryptodev driver.
- *
- * @param driver
- * Pointer to rte_driver.
- * @return
- * The driver type identifier
- */
-uint8_t rte_cryptodev_allocate_driver(const struct rte_driver *driver);
-
-
-#define RTE_PMD_REGISTER_CRYPTO_DRIVER(drv, driver_id)\
-RTE_INIT(init_ ##driver_id);\
-static void init_ ##driver_id(void)\
-{\
- driver_id = rte_cryptodev_allocate_driver(&(drv).driver);\
-}
-
-
#ifdef __cplusplus
}
#endif
@@ -65,6 +65,13 @@ struct rte_cryptodev_global {
uint8_t max_devs; /**< Max number of devices */
};
+/* Cryptodev driver, containing the driver ID */
+struct cryptodev_driver {
+ TAILQ_ENTRY(cryptodev_driver) next; /**< Next in list. */
+ const struct rte_driver *driver;
+ uint8_t id;
+};
+
/** pointer to global crypto devices data structure. */
extern struct rte_cryptodev_global *rte_cryptodev_globals;
@@ -405,6 +412,29 @@ void rte_cryptodev_pmd_callback_process(struct rte_cryptodev *dev,
int
rte_cryptodev_pmd_create_dev_name(char *name, const char *dev_name_prefix);
+/**
+ * @internal
+ * Allocate Cryptodev driver.
+ *
+ * @param crypto_drv
+ * Pointer to cryptodev_driver.
+ * @param drv
+ * Pointer to rte_driver.
+ *
+ * @return
+ * The driver type identifier
+ */
+uint8_t rte_cryptodev_allocate_driver(struct cryptodev_driver *crypto_drv,
+ const struct rte_driver *drv);
+
+
+#define RTE_PMD_REGISTER_CRYPTO_DRIVER(crypto_drv, drv, driver_id)\
+RTE_INIT(init_ ##driver_id);\
+static void init_ ##driver_id(void)\
+{\
+ driver_id = rte_cryptodev_allocate_driver(&crypto_drv, &(drv).driver);\
+}
+
static inline void *
get_session_private_data(const struct rte_cryptodev_sym_session *sess,
uint8_t driver_id) {