From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 267DA45804 for ; Fri, 23 Aug 2024 18:24:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 21AE04336D; Fri, 23 Aug 2024 18:24:14 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 454E6402BE for ; Fri, 23 Aug 2024 18:24:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1724430251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bMa12LdIy+TDtRf974aAvlS5de6Th823Kf/PDRKzEqg=; b=BBb+JAwfhEdosvNndx9YZwaGTUxGYYYLaRFXoNj9GMiOivD/GmPIxUklWuvrj6l7NkOllv I/13mQwAkOzKJRTqdiT0b2r4sugyAzHkibbEaym2LJgJzNuzHTd35kz7R49/t8seuvbBTt +aj9icFLYi12hro3ZTjohUQdhxztCZc= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-3-MpnBZehROAyFlMlFHUNkgA-1; Fri, 23 Aug 2024 12:24:08 -0400 X-MC-Unique: MpnBZehROAyFlMlFHUNkgA-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id D3C7A19560AB; Fri, 23 Aug 2024 16:24:07 +0000 (UTC) Received: from rh.redhat.com (unknown [10.39.193.224]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id A2D6C19560A3; Fri, 23 Aug 2024 16:24:06 +0000 (UTC) From: Kevin Traynor To: Anatoly Burakov Cc: dpdk stable Subject: patch 'malloc: fix multi-process wait condition handling' has been queued to stable release 21.11.8 Date: Fri, 23 Aug 2024 17:19:18 +0100 Message-ID: <20240823161929.1004778-130-ktraynor@redhat.com> In-Reply-To: <20240823161929.1004778-1-ktraynor@redhat.com> References: <20240823161929.1004778-1-ktraynor@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hi, FYI, your patch has been queued to stable release 21.11.8 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 08/28/24. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/kevintraynor/dpdk-stable This queued commit can be viewed at: https://github.com/kevintraynor/dpdk-stable/commit/084ed2a496e84732b77c2d14e0e6711d1c909453 coverity's Thanks. Kevin --- >From 084ed2a496e84732b77c2d14e0e6711d1c909453 Mon Sep 17 00:00:00 2001 From: Anatoly Burakov Date: Fri, 12 Jul 2024 12:41:35 +0100 Subject: [PATCH] malloc: fix multi-process wait condition handling [ upstream commit 429219adab185909a8127e680d19f7628af62fb2 ] >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") Signed-off-by: Anatoly Burakov --- lib/eal/common/malloc_mp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/eal/common/malloc_mp.c b/lib/eal/common/malloc_mp.c index 8e236ddd7b..2817aaa627 100644 --- a/lib/eal/common/malloc_mp.c +++ b/lib/eal/common/malloc_mp.c @@ -756,5 +756,6 @@ request_to_primary(struct malloc_mp_req *user_req) 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) { -- 2.46.0 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2024-08-23 17:18:13.593007135 +0100 +++ 0130-malloc-fix-multi-process-wait-condition-handling.patch 2024-08-23 17:18:09.893430710 +0100 @@ -1 +1 @@ -From 429219adab185909a8127e680d19f7628af62fb2 Mon Sep 17 00:00:00 2001 +From 084ed2a496e84732b77c2d14e0e6711d1c909453 Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit 429219adab185909a8127e680d19f7628af62fb2 ] + @@ -21 +22,0 @@ -Cc: stable@dpdk.org @@ -29 +30 @@ -index 2d39b0716f..9765277f5d 100644 +index 8e236ddd7b..2817aaa627 100644 @@ -32 +33 @@ -@@ -757,5 +757,6 @@ request_to_primary(struct malloc_mp_req *user_req) +@@ -756,5 +756,6 @@ request_to_primary(struct malloc_mp_req *user_req)