[PATCH v3 2/2] crypto/ipsec_mb: fix QP release in secondary

[Burakov, Anatoly]

On 7/19/2025 5:32 PM, Yang Ming wrote:
> When a secondary process tries to release a queue pair (QP) that
> does not belong to it, error logs occur:
> CRYPTODEV: ipsec_mb_ipc_request() line 373: Unable to release
> qp_id=0
> EAL: Message data is too long
> EAL: Fail to handle message: ipsec_mb_mp_msg
> EAL: Fail to recv reply for request /tmp/dpdk/l2hi/mp_socket:
> ipsec_mb_mp_msg
> 
>  From the code path, cryptodev->data is allocated in the primary
> via rte_cryptodev_data_alloc() (inside
> ipsec_mb_create-->rte_cryptodev_pmd_create
> -->rte_cryptodev_pmd_allocate-->rte_cryptodev_data_alloc).
> This memory is placed in a shared memzone
> (rte_cryptodev_data_%u), so both primary and secondary processes
> reference the same cryptodev->data, including nb_queue_pairs and
> queue_pairs[].
> 
> As a result, when the secondary process exits, ipsec_mb_remove()
> is called (inside
> rte_eal_cleanup-->eal_bus_cleanup-->vdev_cleanup
> -->rte_vdev_driver-->ipsec_mb_remove-->ipsec_mb_qp_release
> -->ipsec_mb_secondary_qp_op) and it loops through all queue
> pairs using:
> for (qp_id = 0; qp_id < cryptodev->data->nb_queue_pairs; qp_id++)
>       ipsec_mb_qp_release(cryptodev, qp_id);
> 
> This causes the secondary to attempt releasing queue pairs it
> doesn't own, triggering the error logs mentioned above.
> 
> This patch ensures that a secondary process only frees a QP if
> it actually owns it, preventing conflicts and resolving the
> issue.
> 
> Fixes: b35848bc01f6 ("crypto/ipsec_mb: add multi-process IPC request handler")
> Cc: kai.ji at intel.com
> Cc: stable at dpdk.org
> 
> Signed-off-by: Yang Ming <mosesyyoung at gmail.com>
> ---

Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>

-- 
Thanks,
Anatoly