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 6765C4548C; Tue, 18 Jun 2024 13:42:30 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D4A1140E41; Tue, 18 Jun 2024 13:42:13 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by mails.dpdk.org (Postfix) with ESMTP id 815CC40DD8 for ; Tue, 18 Jun 2024 13:42:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718710929; x=1750246929; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Kq/PQeswvZBF6RBJLn5LrpUvySk2YkZ/faoCbAZeZf8=; b=cSaHD/hc466Vu0B2t+MuNcgu/wytx0bMwNbZ7Bd5uUKQf8LkSbcqDvbj SZgNcYCFHTN7yTzKQyXLGUEHC+W7KOZPm2ELKbFKZVcnvkNJwoVF99vel tGxRJN8FSiewGJaO0fig1KUc1wzd6Ohinc3Pb4Y9zf0dkQzZjcAgYAe59 cqrSnX7EK0Vt4/1xtwV0faEapWBBYyE0F8UAIVum/+dhGTAMyFoUCZrrE QB83YpLF2hzpmTiLxMB08LNa9/PEgDpioCanTGPEZ5VqEGSzIQexjge+r vgYkpdlNjLFxWdz3BFvAy+bUXxdsSNMqveSejY0o0kTjtHUfC4/KRnAOr g==; X-CSE-ConnectionGUID: tqd6qEbKTIaFp7NJzFXQig== X-CSE-MsgGUID: 67dAapjqRVWLf6gMN4VFpQ== X-IronPort-AV: E=McAfee;i="6700,10204,11106"; a="19443302" X-IronPort-AV: E=Sophos;i="6.08,247,1712646000"; d="scan'208";a="19443302" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2024 04:42:08 -0700 X-CSE-ConnectionGUID: ihjlUQQeTIOYnPfpCfAZNg== X-CSE-MsgGUID: /q8PnbAjRUGtNd+K2b5wGg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,247,1712646000"; d="scan'208";a="41621090" Received: from unknown (HELO npf-hyd-clx-03..) ([10.145.170.182]) by fmviesa009.fm.intel.com with ESMTP; 18 Jun 2024 04:42:07 -0700 From: Soumyadeep Hore To: bruce.richardson@intel.com, anatoly.burakov@intel.com Cc: dev@dpdk.org Subject: [PATCH v4 04/21] common/idpf: avoid defensive programming Date: Tue, 18 Jun 2024 10:57:05 +0000 Message-ID: <20240618105722.2326987-5-soumyadeep.hore@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240618105722.2326987-1-soumyadeep.hore@intel.com> References: <20240612035257.2245824-11-soumyadeep.hore@intel.com> <20240618105722.2326987-1-soumyadeep.hore@intel.com> 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 Based on the upstream feedback, driver should not use any defensive programming strategy by checking for NULL pointers and other conditional checks unnecessarily in the code flow to fall back, instead fail and fix the bug in a proper way. As the control queue is freed and deleted from the list after the idpf_ctlq_shutdown call, there is no need to have the ring_size check in idpf_ctlq_shutdown. Signed-off-by: Soumyadeep Hore --- drivers/common/idpf/base/idpf_controlq.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/common/idpf/base/idpf_controlq.c b/drivers/common/idpf/base/idpf_controlq.c index a82ca628de..d9ca33cdb9 100644 --- a/drivers/common/idpf/base/idpf_controlq.c +++ b/drivers/common/idpf/base/idpf_controlq.c @@ -98,9 +98,6 @@ static void idpf_ctlq_shutdown(struct idpf_hw *hw, struct idpf_ctlq_info *cq) { idpf_acquire_lock(&cq->cq_lock); - if (!cq->ring_size) - goto shutdown_sq_out; - #ifdef SIMICS_BUILD wr32(hw, cq->reg.head, 0); wr32(hw, cq->reg.tail, 0); @@ -115,7 +112,6 @@ static void idpf_ctlq_shutdown(struct idpf_hw *hw, struct idpf_ctlq_info *cq) /* Set ring_size to 0 to indicate uninitialized queue */ cq->ring_size = 0; -shutdown_sq_out: idpf_release_lock(&cq->cq_lock); idpf_destroy_lock(&cq->cq_lock); } -- 2.43.0