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 B12514705A for ; Tue, 16 Dec 2025 17:12:07 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A71B64026D; Tue, 16 Dec 2025 17:12:07 +0100 (CET) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by mails.dpdk.org (Postfix) with ESMTP id 6B286402DE for ; Tue, 16 Dec 2025 17:12:03 +0100 (CET) Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-8b31a665ba5so598883985a.2 for ; Tue, 16 Dec 2025 08:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytheb-org.20230601.gappssmtp.com; s=20230601; t=1765901522; x=1766506322; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Z5myHXoKlv9k8YmcDuq8UIfBf3KG4Zd1Rw8eSJZTCIU=; b=ORK/vFnrVGWrBFJPQP2eJabpB8gy/JStqUzjWrnT65xgA6Ham4uenZJtTBj3O+OJwE sMh/pLd6dP0cKsAfua9tpKA7NRvBNBe6vgeL9QCnA8jSvN1CnHLthEnONC92avgeoNsp go9AX7nu8wVJXktcdUACsRtiwVfgKJ05dntZm4izI+GTvqUiV4F7KCZWdOmdVfY/Mu03 LLJetXsXeNLTQOORiAWkfUaLwOeMOYblzBN+a2rVN88DclyZ6if6oRU5AHFEMK9yllZf xXhaLIU7dvoxKzWOaFMGk2i4T+VsL1Pq8RRN7xdTO2PaXNITV+P+VVQsVh0ZT4akihiy GIyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765901522; x=1766506322; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=Z5myHXoKlv9k8YmcDuq8UIfBf3KG4Zd1Rw8eSJZTCIU=; b=dtLSQik4tWdunnvbp7Ewp8Pjf6fX8+tVmsvvPbalagiSNTKaN3S9zabbcDur+Qv67H 6617NvwZcPeaIYoobMQkk75s/aJ9AXvjXGcd/+88cGwH/hKE1ZsejPmOs96pFMuOgbP5 vQsu9FeUBrdUho3a4M4f9/316T83UD+ek0e8qNkSsFscLaVlGqPsAQMfJ8TdTGq95xOy LpLBsbSO4FRHer/HzSLRpmKXu3lNWwO4tBgmxRPL3jd4PjdXSV/GLQXMQUuWKIL9aE7I bpYgcJDZoFGSZL8yJkUwriNNBYkPsbnf3cVpNI2mQOb0GyX9VybO910lbPYPngcYOgvK AYNA== X-Gm-Message-State: AOJu0YxntNGL6ZXW7PjMo707TXk7rfCROLvoK1s466pcAr+EflOxOjsS 250i5h++OVFQR3dy6upQsol7ZEOJdbvsPuRfC3NyN6yj1sCXMQSbV5LaE9RWZp12IwRNBJ3HY7v Cbz6M X-Gm-Gg: AY/fxX5q7bSgBNAgSx4VnqOlLcfcwXeBuB6qJ2tTLplPm0a7aM9LKT3LOouAvDFMg5c 3VviFL9ngeEa8nL3tOTbAxqraSzvdVSsX082x3UcrDkZW7blWC2VJFg7rOdsBGIADKKtf4vn9kl q2pOGNeP7J7xKqar/gU4kyXa7oTTvIu71vt+h8A2rb5ctTcBT8O7HXapYFDs7JwYzGZEdHJmUCf DS//vnwXEkalnOATBo+hXHxn0BdTDSu7MAwqxByjgiyGJzRQRws7mp4RQYBNCD6Jjd6wcqA15+X akfObdnrMU7M+2+wIOqziLwARCIARfw+fGiKoohE2UFiyD9MYI6EwjucfgmTWAIXJa4H8GAYBrw yZCNVpF8FT90OO3GMuMJ3CSdvxCNAlr2uUVZbFlc4wuHaZ3ffoSOcUpMo3+QbJ00aJnyusXE5W2 Xn/zH8rs5wUxpWcfCMo5p4GipSSoGr X-Google-Smtp-Source: AGHT+IGsuXXn5ei2RJdNFcASV2z4uYb8M6o/4JgKkDbuQriIqrIIhbhV06R44rpO9E1CVCdYEHooFw== X-Received: by 2002:a05:622a:5918:b0:4ee:ee46:842f with SMTP id d75a77b69052e-4f1d046709dmr183951101cf.9.1765901522245; Tue, 16 Dec 2025 08:12:02 -0800 (PST) Received: from RHTRH0061144.redhat.com ([47.14.5.10]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-4f345b4b894sm18643081cf.12.2025.12.16.08.12.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 08:12:01 -0800 (PST) From: 0-day Robot To: test-report@dpdk.org, Stephen Hemminger Subject: |SUCCESS| pw159213 [PATCH v5 02/17] lpm: restrict name size Date: Tue, 16 Dec 2025 11:12:00 -0500 Message-ID: <20251216161200.762462-1-robot@bytheb.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251207191242.165619-3-stephen@networkplumber.org> References: <20251205022948.327743-1-stephen@networkplumber.org> <20251207191242.165619-1-stephen@networkplumber.org> <20251207191242.165619-3-stephen@networkplumber.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: test-report@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: automatic DPDK test reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: test-report-bounces@dpdk.org Test-Label: 0day Robot - Claude SONNET Test-Status: SUCCESS http://dpdk.org/patch/159213 _AI Review Comments Available_ Looking at this patch, I have a few concerns about the implementation and approach. commit: (not provided in patch headers) Author: Stephen Hemminger lpm: restrict name size > Subject: [PATCH v5 02/17] lpm: restrict name size > > Since LPM uses ring internally with a prefix, limit the > maximum allowed LPM name. > > Signed-off-by: Stephen Hemminger > --- > lib/lpm/rte_lpm.c | 25 +++++++++++++++++++------ > lib/lpm/rte_lpm.h | 2 +- > 2 files changed, 20 insertions(+), 7 deletions(-) > > diff --git a/lib/lpm/rte_lpm.c b/lib/lpm/rte_lpm.c > index 6dab86a05e..2666d4f208 100644 > --- a/lib/lpm/rte_lpm.c > +++ b/lib/lpm/rte_lpm.c > @@ -5,6 +5,7 @@ > > #include > #include > +#include > #include > #include > #include [ ... ] > @@ -152,7 +153,6 @@ struct rte_lpm * > rte_lpm_create(const char *name, int socket_id, > const struct rte_lpm_config *config) > { > - char mem_name[RTE_LPM_NAMESIZE]; > struct __rte_lpm *i_lpm; > struct rte_lpm *lpm = NULL; > struct rte_tailq_entry *te; > @@ -170,7 +170,15 @@ rte_lpm_create(const char *name, int socket_id, > return NULL; > } > > - snprintf(mem_name, sizeof(mem_name), "LPM_%s", name); > + if (strlen(name) >= RTE_LPM_NAMESIZE) { > + rte_errno = ENAMETOOLONG; > + return NULL; > + } > + > + /* This is only used for tracing, ok to be NULL */ > + char *mem_name = NULL; > + int unused __rte_unused; > + unused = asprintf(&mem_name, "LPM_%s", name); Does this code leak mem_name when asprintf fails? The asprintf function allocates memory that needs to be freed, but if it fails and returns -1, mem_name becomes undefined and might not be NULL. Would it be more robust to check the return value and set mem_name to NULL on failure rather than using the __rte_unused annotation? > > rte_mcfg_tailq_write_lock(); > [ ... ] > @@ -247,6 +255,7 @@ rte_lpm_create(const char *name, int socket_id, > > exit: > rte_mcfg_tailq_write_unlock(); > + free(mem_name); Can this code safely call free on mem_name if asprintf failed? When asprintf returns -1, the state of mem_name is undefined according to POSIX - it might not be safe to pass to free(). > > return lpm; > } [ ... ] > @@ -326,9 +334,13 @@ rte_lpm_rcu_qsbr_add(struct rte_lpm *lpm, struct rte_lpm_rcu_config *cfg) > if (cfg->mode == RTE_LPM_QSBR_MODE_SYNC) { > /* No other things to do. */ > } else if (cfg->mode == RTE_LPM_QSBR_MODE_DQ) { > + char rcu_dq_name[RTE_RCU_QSBR_DQ_NAMESIZE]; > + > /* Init QSBR defer queue. */ > - snprintf(rcu_dq_name, sizeof(rcu_dq_name), > - "LPM_RCU_%s", i_lpm->name); > + if (snprintf(rcu_dq_name, sizeof(rcu_dq_name), > + "LPM_RCU_%s", i_lpm->name) >= (int)sizeof(rcu_dq_name)) > + LPM_LOG(NOTICE, "LPM rcu defer queue name truncated"); Should this function return an error when the RCU defer queue name gets truncated? Operating with a truncated name might cause collisions or other unexpected behavior. > diff --git a/lib/lpm/rte_lpm.h b/lib/lpm/rte_lpm.h > index edfe77b458..8e70603ace 100644 > --- a/lib/lpm/rte_lpm.h > +++ b/lib/lpm/rte_lpm.h > @@ -26,7 +26,7 @@ extern "C" { > #endif > > /** Max number of characters in LPM name. */ > -#define RTE_LPM_NAMESIZE 32 > +#define RTE_LPM_NAMESIZE RTE_RING_NAMESIZE Is it correct to assume RTE_RING_NAMESIZE is always available when this header is included? This creates a dependency that might not be obvious to users of the LPM library.