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 33E2FA034D for ; Fri, 25 Feb 2022 18:34:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2C73641151; Fri, 25 Feb 2022 18:34:18 +0100 (CET) Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by mails.dpdk.org (Postfix) with ESMTP id 0FDC74113D for ; Fri, 25 Feb 2022 18:34:15 +0100 (CET) Received: by mail-pj1-f53.google.com with SMTP id gb21so5359578pjb.5 for ; Fri, 25 Feb 2022 09:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=WFm15tmmzXkSq1thTpGc9i2Qn1hpRcW5xTp0Y5EMU9A=; b=kp4VjgDR5SmIjN/6nsUfjyQrqYRXE/ZxK+sROSZzM3hrbNRWlstqvkv9yY4g5nbAA7 NP9ZFwaAMLuh3bUB+qK/U6Xh9Ey0AuTRTv/pXJaPIUyGkpBvoOQo272EhpqX/hPxuyMg Zg2eFCpSe9JOmOr+B5H2XFKYjZbeW/6kKJiI9ZDjrq7PmkDs2Ys8h/ikiB3yS6l45BGI DqBZGB2zGx+yb5fDEFNkqljjSAN8KOWzEdK4p0g+kV2sup6JQpQaRcSbmrIki2RP/Z71 nRE/nP4ZizRNAZo8hRN1l1ocb6fOcvymwKGckbwSfNPYYG+CMX/qvNj+WsSF+X+Y+lmW OilA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=WFm15tmmzXkSq1thTpGc9i2Qn1hpRcW5xTp0Y5EMU9A=; b=tK19w0kOPBQaKoNbJwOTK3zBcb/8CLHtTSessDyVUGaWaDBmnXjZ4h5ISaO5hJ0Ba0 4Jq2gBsGaeAa/w8C41S93GW3EIlRwRuQ2IKKxS424HSCTK9f4/4+wBQ6oCi2fdDjNqY4 a49iZwcxiIHS2wFlGIB0CJ5u46xIcRX7Ihm0AVN0arbHgrXNdIrgOkmSErErGtVU2iDM HuqRj7Zfsrb049fhuSQq/jz1G0nujlXNXShKHuua3vr7/EXMsstfVbyviPJRct7xTD/5 wLlTMKD5gkFAUCsfZyqxD7IVI+3r/ZBISpshjjghjT+oYlBgFF2LgbF1cFloLl2UTwBX jCaw== X-Gm-Message-State: AOAM5326BlpTHBKZk+/J3JSb8vJV0xq7e1P32Yf682/MEAQLFtrULzD5 5pO51QGaa/Nb+ioQPQejAvVjnA== X-Google-Smtp-Source: ABdhPJxLs+9nw106f+DqFOipU0LT1nAMQIqinNuufVKwVWbCWTxgkiOZDaEgnYktmicxtaNSMsEPgw== X-Received: by 2002:a17:90a:5291:b0:1bb:ef4d:947d with SMTP id w17-20020a17090a529100b001bbef4d947dmr4147613pjh.243.1645810455016; Fri, 25 Feb 2022 09:34:15 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id n22-20020a056a0007d600b004f3ba7c23e2sm3999480pfu.37.2022.02.25.09.34.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Feb 2022 09:34:14 -0800 (PST) Date: Fri, 25 Feb 2022 09:34:11 -0800 From: Stephen Hemminger To: Reshma Pattan Cc: dev@dpdk.org, ferruh.yigit@intel.com, vipin.varghese@intel.com, stable@dpdk.org Subject: Re: [PATCH v3] app/pdump: check lcore is not the maximum core Message-ID: <20220225093411.0e5f9d02@hermes.local> In-Reply-To: <20220222110224.56857-1-reshma.pattan@intel.com> References: <20220221101944.4216-1-reshma.pattan@intel.com> <20220222110224.56857-1-reshma.pattan@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 22 Feb 2022 11:02:24 +0000 Reshma Pattan wrote: > Check lcore id value is not the maximum core supported. > Using lcore id without this check might cause > out of bound access inside the rte_eal_wait_lcore. > > Coverity issue: 375841 > Fixes: b2854d5317e8 ("app/pdump: support multi-core capture") > Cc: vipin.varghese@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Reshma Pattan > --- > v3: add new function to get next core id and validate it. > --- > app/pdump/main.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/app/pdump/main.c b/app/pdump/main.c > index 04a38e8911..e4e62811c9 100644 > --- a/app/pdump/main.c > +++ b/app/pdump/main.c > @@ -900,6 +900,15 @@ dump_packets_core(void *arg) > return 0; > } > > +static inline void > +get_next_core(uint32_t *lcore_id) > +{ > + *lcore_id = rte_get_next_lcore(*lcore_id, 1, 0); > + if (*lcore_id == RTE_MAX_LCORE) > + rte_exit(EXIT_FAILURE, > + "Max core limit %u reached for packet capture", *lcore_id); > +} > + This looks good, can I make a some suggestions. Since function either exits or returns a good value, I would prefer that it returned the lcore id. Avoiding call by reference if possible. Also, the lcore is currently typed unsigned int in rte_lcore.h therefore use that type? Inline is certainly unnecessary here, not critical path and compiler is likely to do it anyway. Also, DPDK uses lcore for most places (rather than core) so use that name. Result is: static unsigned int get_next_lcore(unsigned int lcore) { lcore = rte_get_next_lcore(lcore, 1, 0); if (lcore >= RTE_MAX_LCORE) "Max core limit %u reached for packet capture", lcore); return lcore; } > static inline void > dump_packets(void) > { > @@ -930,12 +939,12 @@ dump_packets(void) > return; > } > > - lcore_id = rte_get_next_lcore(lcore_id, 1, 0); > + get_next_core(&lcore_id); > > for (i = 0; i < num_tuples; i++) { > rte_eal_remote_launch(dump_packets_core, > &pdump_t[i], lcore_id); > - lcore_id = rte_get_next_lcore(lcore_id, 1, 0); > + get_next_core(&lcore_id); > > if (rte_eal_wait_lcore(lcore_id) < 0) > rte_exit(EXIT_FAILURE, "failed to wait\n");