From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Piotr Krzewinski <piotr.krzewinski@ericsson.com>,
Akhil Goyal <gakhil@marvell.com>,
Fan Zhang <fanzhang.oss@gmail.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH] cryptodev: fix memory corruption in secondary process
Date: Thu, 26 Feb 2026 15:53:06 +0100 [thread overview]
Message-ID: <431e978a-1763-43b0-a2c9-d285edbbfec8@intel.com> (raw)
In-Reply-To: <20260226135727.4171394-1-piotr.krzewinski@ericsson.com>
On 2/26/2026 2:57 PM, Piotr Krzewinski wrote:
> When secondary process runs with --no-pci, it skips hardware device
> probing, causing different cryptodev dev_id assignments than in primary.
> Since memzone lookup is based on dev_id, it leads to secondary
> attaching to wrong memzone and corrupting primary's device
> data structures.
This probably would be the case even if you didn't use `--no-pci` but
instead were using block-lists/allow-lists to only probe different
devices in secondary processes? Maybe the problem is more general than that.
>
> Fix by making secondary process search for devices by name in existing
> memzones instead of using local dev_id allocation.
>
> Signed-off-by: Piotr Krzewinski <piotr.krzewinski@ericsson.com>
> ---
> lib/cryptodev/rte_cryptodev.c | 37 +++++++++++++++++++++++++++++++----
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
> index 7bddb154c2..50071935c2 100644
> --- a/lib/cryptodev/rte_cryptodev.c
> +++ b/lib/cryptodev/rte_cryptodev.c
> @@ -1177,6 +1177,27 @@ rte_cryptodev_find_free_device_index(void)
> return RTE_CRYPTO_MAX_DEVS;
> }
>
> +static uint8_t
> +rte_cryptodev_find_device_by_name(const char *name)
> +{
> + char mz_name[RTE_MEMZONE_NAMESIZE];
> + const struct rte_memzone *mz;
> + struct rte_cryptodev_data *data;
> + uint8_t dev_id;
> +
> + for (dev_id = 0; dev_id < RTE_CRYPTO_MAX_DEVS; dev_id++) {
> + snprintf(mz_name, sizeof(mz_name), "rte_cryptodev_data_%u", dev_id);
> + mz = rte_memzone_lookup(mz_name);
> + if (mz == NULL)
> + continue;
> +
> + data = mz->addr;
> + if (strncmp(data->name, name, RTE_CRYPTODEV_NAME_MAX_LEN) == 0)
> + return dev_id;
> + }
> + return RTE_CRYPTO_MAX_DEVS;
> +}
Nitpicking, but why not return `int` and -1? Returning
RTE_CRYPTO_MAX_DEVS seems like an odd choice here. You can always cast
the valid value to uint8_t at the caller.
That said,
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
> +
> RTE_EXPORT_INTERNAL_SYMBOL(rte_cryptodev_pmd_allocate)
> struct rte_cryptodev *
> rte_cryptodev_pmd_allocate(const char *name, int socket_id)
> @@ -1190,10 +1211,18 @@ rte_cryptodev_pmd_allocate(const char *name, int socket_id)
> return NULL;
> }
>
> - dev_id = rte_cryptodev_find_free_device_index();
> - if (dev_id == RTE_CRYPTO_MAX_DEVS) {
> - CDEV_LOG_ERR("Reached maximum number of crypto devices");
> - return NULL;
> + if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
> + dev_id = rte_cryptodev_find_device_by_name(name);
> + if (dev_id == RTE_CRYPTO_MAX_DEVS) {
> + CDEV_LOG_ERR("Device %s does not exist in primary process", name);
> + return NULL;
> + }
> + } else {
> + dev_id = rte_cryptodev_find_free_device_index();
> + if (dev_id == RTE_CRYPTO_MAX_DEVS) {
> + CDEV_LOG_ERR("Reached maximum number of crypto devices");
> + return NULL;
> + }
> }
>
> cryptodev = rte_cryptodev_pmd_get_dev(dev_id);
--
Thanks,
Anatoly
next prev parent reply other threads:[~2026-02-26 14:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-26 13:57 [PATCH] cryptodev: fix memory corruption in secondary process Piotr Krzewinski
2026-02-26 14:53 ` Burakov, Anatoly [this message]
2026-02-27 7:54 ` Piotr Krzewinski
2026-03-10 5:54 ` [EXTERNAL] " Akhil Goyal
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=431e978a-1763-43b0-a2c9-d285edbbfec8@intel.com \
--to=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=fanzhang.oss@gmail.com \
--cc=gakhil@marvell.com \
--cc=piotr.krzewinski@ericsson.com \
/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