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 54465A034C; Fri, 25 Feb 2022 18:34:17 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3DFF74113D; Fri, 25 Feb 2022 18:34:17 +0100 (CET) Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) by mails.dpdk.org (Postfix) with ESMTP id F04D9410FD for ; Fri, 25 Feb 2022 18:34:15 +0100 (CET) Received: by mail-pj1-f48.google.com with SMTP id m13-20020a17090aab0d00b001bbe267d4d1so8057178pjq.0 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=0U99LszuBoIuo1rIhN+vtHDY8CnJqu1N69EAYrooqR9T6YWCLBBvMwKkmuuT4ILoNx 0Sn33feBFKDokikt7PV4INh5G0kDPdfRgvi7h4pWph51AjcfRxVu/S5mBcQVhLqa/bxv vp1mJqSvIE75b0LqNNAiqLr9xZQjZG+xDGPtvotNpbMPjf8ljlWBtlqc64JzgkHOLfk0 jTGUm/Vde++kXA0ojjE87ac/vNv4mU5oBFnaDrURJgSncbp2ggjICMQ/VrcBGJAT+JW0 4wmfwMBDbhJuKaN7b30gdOMls0j2wAo7L+Aryw/DngB4a134ItmBwY0GPLgvqNG7EBFX OgUA== X-Gm-Message-State: AOAM5311g0pxVA9VwyfCqAAwHrdPaxoDZs4a6P++mREX4MOa7AfdLvCl BfO6E3bu/4wu/luyTZff/HhY4g== 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: 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 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");