[PATCH] Coverity issue: Failure to enqueue packets for cryptodev-scheduler_multicore can lead to program crashes Bugzilla ID: 1537 Fixes: replace `pending_deq_ops` with `pending_enq_ops` Cc: stable@dpdk.org

[PATCH] Coverity issue: Failure to enqueue packets for cryptodev-scheduler_multicore can lead to program crashes Bugzilla ID: 1537 Fixes: replace `pending_deq_ops` with `pending_enq_ops` Cc: stable@dpdk.org

[Yong Liang]

Signed-off-by: Yong Liang <1269690261@qq.com>
---
 drivers/crypto/scheduler/scheduler_multicore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/scheduler/scheduler_multicore.c b/drivers/crypto/scheduler/scheduler_multicore.c
index a21b522f9f..70f8a25b70 100644
--- a/drivers/crypto/scheduler/scheduler_multicore.c
+++ b/drivers/crypto/scheduler/scheduler_multicore.c
@@ -191,11 +191,11 @@ mc_scheduler_worker(struct rte_cryptodev *dev)
 					worker->qp_id,
 					&enq_ops[pending_enq_ops_idx],
 					pending_enq_ops);
-			if (processed_ops < pending_deq_ops)
+			if (processed_ops < pending_enq_ops)
 				scheduler_retrieve_sessions(
 					&enq_ops[pending_enq_ops_idx +
 						processed_ops],
-					pending_deq_ops - processed_ops);
+					pending_enq_ops - processed_ops);
 			pending_enq_ops -= processed_ops;
 			pending_enq_ops_idx += processed_ops;
 			inflight_ops += processed_ops;
-- 
2.46.0.windows.1

[PATCH] Coverity issue: Failure to enqueue packets for cryptodev-scheduler_multicore can lead to program crashes Bugzilla ID: 1537 Fixes: replace `pending_deq_ops` with `pending_enq_ops` Cc: stable@dpdk.org

[Yong Liang]

Signed-off-by: Yong Liang <1269690261@qq.com>
---
 drivers/crypto/scheduler/scheduler_multicore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/scheduler/scheduler_multicore.c b/drivers/crypto/scheduler/scheduler_multicore.c
index a21b522f9f..70f8a25b70 100644
--- a/drivers/crypto/scheduler/scheduler_multicore.c
+++ b/drivers/crypto/scheduler/scheduler_multicore.c
@@ -191,11 +191,11 @@ mc_scheduler_worker(struct rte_cryptodev *dev)
 					worker->qp_id,
 					&enq_ops[pending_enq_ops_idx],
 					pending_enq_ops);
-			if (processed_ops < pending_deq_ops)
+			if (processed_ops < pending_enq_ops)
 				scheduler_retrieve_sessions(
 					&enq_ops[pending_enq_ops_idx +
 						processed_ops],
-					pending_deq_ops - processed_ops);
+					pending_enq_ops - processed_ops);
 			pending_enq_ops -= processed_ops;
 			pending_enq_ops_idx += processed_ops;
 			inflight_ops += processed_ops;
-- 
2.46.0.windows.1

Re: [PATCH] Coverity issue: Failure to enqueue packets for cryptodev-scheduler_multicore can lead to program crashes Bugzilla ID: 1537 Fixes: replace `pending_deq_ops` with `pending_enq_ops` Cc: stable@dpdk.org

[Stephen Hemminger]

On Tue, 10 Sep 2024 00:48:22 +0800
Yong Liang <1269690261@qq.com> wrote:

> Signed-off-by: Yong Liang <1269690261@qq.com>

This is not the correct way to put the covertity and bugzilla information into the patch.
The infrastruture expects:

1. Put the short description in the Subject line of the email.

2. Add a longer description of what the problem is in the git commit
log (body of the email)

3. Put the Coverity Issue in as a line before the Signed-off-by in the commit log.

4. Put the Bugzilla ID in as line before the Signed-off-by

5. Put the Fixes line in before the Signed-off-by

Example:

commit 429219adab185909a8127e680d19f7628af62fb2
Author: Anatoly Burakov <anatoly.burakov@intel.com>
Date:   Fri Jul 12 12:41:35 2024 +0100

    malloc: fix multi-process wait condition handling
    
    From coverity's point of view, it is theoretically possible to have an
    infinite wait on a wait condition because while we do check for timeout,
    we do not check for whether the event we are waiting for has already
    occurred by the time we get to the first cond_wait call (in this case,
    it's state of memory request list entry's state being set to COMPLETE).
    
    This can't really happen as the only time a wait condition is triggered
    is when we are receiving a memory event (so the entry we are waiting on
    cannot change before wait condition is triggered because it's protected
    by a mutex), so either we receive an event and modify entry state, or we
    exit wait on a timeout and do not care about request state. However, it's
    better to keep coverity happy.
    
    Coverity issue: 425709
    Fixes: 07dcbfe0101f ("malloc: support multiprocess memory hotplug")
    Cc: stable@dpdk.org
    
    Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>