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 C08A745610; Fri, 12 Jul 2024 13:41:56 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E790740A89; Fri, 12 Jul 2024 13:41:55 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by mails.dpdk.org (Postfix) with ESMTP id 522EA402F0; Fri, 12 Jul 2024 13:41:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1720784513; x=1752320513; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=Iyvu8yAn3BSK0jot8ucsjxT2BfvPjRN1hiUfe9KQreM=; b=FkLOJ0WDoJU7WZvT2vfOg7j7rsEomRCiPj7OzVBDORbvgznBSl6f9gHT md5a12LnJv/tzIpzlOPeIbd8LzzFbX3YB6MB0JH38EttMQMf6ATbkHrV1 CFG1URqy6r5D7ZL+QDxc9/jEpqVfp8o1e3wL/Megft3+t/GWe8GSlAs+Z D4yPwKdzA2JXd5MhsFc5bUhqZni+gm/kfWIex4ZRdB3M2fXJok69zjyvy JrwT0x0LFXuri97s23q9hvncTCG96gBpFEJKnv0QQC7yiXmYE32UrzoCN 4RCE7s+y3R2MI4nHtqc8dphrfMG9T4yN3lyqEhxMzjAWp0+nMJzIs2Ttr Q==; X-CSE-ConnectionGUID: EnZZ4x3cRxaHduOhwo6QjQ== X-CSE-MsgGUID: BDVIrIu9SZ6nrRUAVkmYcg== X-IronPort-AV: E=McAfee;i="6700,10204,11130"; a="28811330" X-IronPort-AV: E=Sophos;i="6.09,202,1716274800"; d="scan'208,223";a="28811330" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jul 2024 04:41:37 -0700 X-CSE-ConnectionGUID: UJKxy8gXQ7WhP/Oj0E2faw== X-CSE-MsgGUID: ZfxF+FJnROOuKFN/x0OkoQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,202,1716274800"; d="scan'208,223";a="48897799" Received: from silpixa00401119.ir.intel.com ([10.55.129.167]) by fmviesa009.fm.intel.com with ESMTP; 12 Jul 2024 04:41:36 -0700 From: Anatoly Burakov To: dev@dpdk.org, Tyler Retzlaff Cc: stable@dpdk.org Subject: [PATCH v1 1/1] malloc/mp: fix wait condition handling Date: Fri, 12 Jul 2024 12:41:35 +0100 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org >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 --- 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 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"); -- 2.43.0