diff mbox series

[v1,1/1] malloc/mp: fix wait condition handling

Message ID a6eb861b5689deaa75493d7399da962c9a4e37d2.1720784477.git.anatoly.burakov@intel.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series [v1,1/1] malloc/mp: fix wait condition handling |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/github-robot: build success github build: passed
ci/intel-Functional success Functional PASS
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-amd64-testing pending Testing pending
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS

Commit Message

Burakov, Anatoly July 12, 2024, 11:41 a.m. UTC 
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>
---
 lib/eal/common/malloc_mp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Thomas Monjalon July 23, 2024, 1:42 p.m. UTC | #1 
12/07/2024 13:41, Anatoly Burakov:
> 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>

Applied, thanks.
diff mbox series

Patch

diff --git a/lib/eal/common/malloc_mp.c b/lib/eal/common/malloc_mp.c
index 2d39b0716f..9765277f5d 100644
--- a/lib/eal/common/malloc_mp.c
+++ b/lib/eal/common/malloc_mp.c
@@ -756,7 +756,8 @@  request_to_primary(struct malloc_mp_req *user_req)
 	do {
 		ret = pthread_cond_timedwait(&entry->cond,
 				&mp_request_list.lock, &ts);
-	} while (ret != 0 && ret != ETIMEDOUT);
+	} while ((ret != 0 && ret != ETIMEDOUT) &&
+			entry->state == REQ_STATE_ACTIVE);
 
 	if (entry->state != REQ_STATE_COMPLETE) {
 		EAL_LOG(ERR, "Request timed out");