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 CC8444705A 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 C0227402DE; Tue, 16 Dec 2025 17:12:07 +0100 (CET) Received: from mail-qv1-f51.google.com (mail-qv1-f51.google.com [209.85.219.51]) by mails.dpdk.org (Postfix) with ESMTP id 067C34026D for ; Tue, 16 Dec 2025 17:12:06 +0100 (CET) Received: by mail-qv1-f51.google.com with SMTP id 6a1803df08f44-8885b3c06caso21119016d6.1 for ; Tue, 16 Dec 2025 08:12:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytheb-org.20230601.gappssmtp.com; s=20230601; t=1765901525; x=1766506325; 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=vEOXQajTL+VHoIOarUHiCxic0c48d9SGGjWYFsvTYB8=; b=n8BJwZz0nTzYuCiKiFF8HCNFbl1bh/cU4P1994VEYBx3+wUeEq9TXdoDWqgf8jWcQy 1Em5cQWXN6R14dyZVY4XTv0FSJAWUL7p8UpN6rUnYj2xXCNJrtE1M2/YgjxKJWiOKbzU gP3p/8g9iLZe2ZulQRsurus09QlzrFsg9BIcAiin9+qA6VkLR7/US5wR8pfzMt+CCHi9 Z0ulxA5FSS5trcFDST60/i/oBzPtlXU64JsKwBqg6iR1tNxrbab6QqpdJRLwojve4fb7 OTYlNldWwN2X3pns3HwPV5vyGvfyN6i3UYskFWulC4mbpLbnYOtGwGodqHfooiUhwa5i kFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765901525; x=1766506325; 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=vEOXQajTL+VHoIOarUHiCxic0c48d9SGGjWYFsvTYB8=; b=bDZJTD2h3QU+9D/L9t8SiO5qE9VFm4PcVNsh/C+yyexApjmlaxqmBNxPvTscVsxtmk kvAvzXsIAN/gc3A5OpIMwmz3NWs8MCGCvNqp7eXO/PShtmb/O19kY3zZFNF0Xrdg5kAp bM6eW0Mz+WpS5fcgMQsuTxZ1m8oasK3p51fEgfNNnRtFc3vQxBU5J/8Hj2SKF9z5tHLO VEHjzHu8+aNqME07ZKLwdj4CeyuSfrUYWmSheC/0QG0LOPOOao0TrdjDqV7nB3RHQIy1 2RCDD8LjZ7lMpiER5fFjOjfNw6e/jSiieyo0o0ye/BR0irZcHF+DO91serdZVaf09KsR an2A== X-Gm-Message-State: AOJu0YxLuDm6jXMZZFo44XvxvuFeC0UTUPzbZ9S31axxyl9vd9mlmgiK FYzPYgF8cKxitSMPGG7WAQiHS/FJXLLtJV3jaqFybaiUHFgjyfrYonubdKMPbeXx3gb/7JSsTc0 00rc7 X-Gm-Gg: AY/fxX4EtHpbhIq/9/rXsPL0ALxnmdXHxBp2dv01kL8JLE3QZKLpyYHdX/1lAHCuh/F kZMMf9esdsmL985wNi9bQbQfuL8GeiZOPpWXfWXFS7DDyNet415Jcx+jTKVdPJaT7Ak5QrAbEWF DpzVYCo7zSwKtvTJqXt/5wLvvIT/1gpxHT8YulgYxIhP5CKjAZ7Ii4F520FD6AVW97cVTqdiBBN 5n5c+hN7IV/gkEmmQ883JYlScdTVbyznxKbqY1V0VHP4GYmoRp4WnTOwMabe7hA17xTYcrGkoM9 dhZsJWDFWGv9MbPoyQQIXjSBiJMmQIOqPSGDCxTFDuORIoY5bJoTnwwy2d7fm52SrbmgzeKeTDC +bLwNVavCjFoKYARb2mvH2PBUO94pOFuBKEcxXcBbGuwNyX0N1l2lZZVKw0Zy3iLR7Hnjh0LiEI 56cL+oZPxX+LDMq7dl6A== X-Google-Smtp-Source: AGHT+IG9TdBjSgQKsOkywPHQycQcqY/IyqDCNvWh4lXPwhWqrUxA7LHASTN1Q0ergi+q4jXXHleDrA== X-Received: by 2002:a05:6214:262b:b0:880:298b:3a6d with SMTP id 6a1803df08f44-8887e0f1218mr220404366d6.35.1765901524652; Tue, 16 Dec 2025 08:12:04 -0800 (PST) Received: from RHTRH0061144.redhat.com ([47.14.5.10]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88993b5c015sm76953416d6.15.2025.12.16.08.12.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Dec 2025 08:12:04 -0800 (PST) From: 0-day Robot To: test-report@dpdk.org, Stephen Hemminger Subject: |SUCCESS| pw159214 [PATCH v5 03/17] hash: add checks for hash name length Date: Tue, 16 Dec 2025 11:12:02 -0500 Message-ID: <20251216161202.762473-1-robot@bytheb.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251207191242.165619-4-stephen@networkplumber.org> References: <20251205022948.327743-1-stephen@networkplumber.org> <20251207191242.165619-1-stephen@networkplumber.org> <20251207191242.165619-4-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/159214 _AI Review Comments Available_ git sha: [Could not determine from patch content] Author: Stephen Hemminger Subject: [PATCH v5 03/17] hash: add checks for hash name length This commit adds name length validation to hash creation functions and improves error handling for ring creation failures. It also adds tests for the new validation logic. > diff --git a/app/test/test_hash.c b/app/test/test_hash.c > index 5791fd7f4c..0b608a3d74 100644 > --- a/app/test/test_hash.c > +++ b/app/test/test_hash.c > @@ -1120,6 +1120,14 @@ fbk_hash_unit_test(void) > .socket_id = RTE_MAX_NUMA_NODES + 1, /* invalid socket */ > }; > > + /* try and create hash with an excessively long name */ > + struct rte_fbk_hash_params invalid_params_long_name = { > + .name = "four_byte_key_hash_name_length_32", > + .entries = 4, > + .entries_per_bucket = 2, > + .socket_id = 0, > + }; > + Is this test name actually long enough to trigger the validation? The test name appears to be exactly 32 characters but the test should verify it exceeds RTE_FBK_HASH_NAMESIZE. [ ... ] > diff --git a/lib/hash/rte_cuckoo_hash.c b/lib/hash/rte_cuckoo_hash.c > index 2c92c51624..f9c4a0e302 100644 > --- a/lib/hash/rte_cuckoo_hash.c > +++ b/lib/hash/rte_cuckoo_hash.c > @@ -278,12 +278,16 @@ rte_hash_create(const struct rte_hash_parameters *params) > else > num_key_slots = params->entries + 1; > > - snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name); > + /* Ring name may get truncated, conflict detected on ring creation */ > + if (snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name) > + >= (int)sizeof(ring_name)) > + HASH_LOG(NOTICE, "ring name truncated to '%s'", ring_name); > + Can this truncation check be reached given the earlier name length validation in rte_hash_create()? The validation should prevent names that would cause truncation when prefixed with "HT_". > @@ -1621,8 +1639,9 @@ rte_hash_rcu_qsbr_add(struct rte_hash *h, struct rte_hash_rcu_config *cfg) > h->dq = rte_rcu_qsbr_dq_create(¶ms); > if (h->dq == NULL) { > rte_free(hash_rcu_cfg); > - HASH_LOG(ERR, "HASH defer queue creation failed"); > + HASH_LOG(ERR, "HASH defer queue creation failed: %s", > + rte_strerror(rte_errno)); Does rte_rcu_qsbr_dq_create() guarantee that rte_errno is set on failure? Without this guarantee, the error message might be misleading. > diff --git a/lib/hash/rte_fbk_hash.c b/lib/hash/rte_fbk_hash.c > index 38b15a14d1..2304db7551 100644 > --- a/lib/hash/rte_fbk_hash.c > +++ b/lib/hash/rte_fbk_hash.c > @@ -83,7 +83,7 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params) > { > struct rte_fbk_hash_table *ht = NULL; > struct rte_tailq_entry *te; > - char hash_name[RTE_FBK_HASH_NAMESIZE]; > + char *hash_name = NULL; > const uint32_t mem_size = > sizeof(*ht) + (sizeof(ht->t[0]) * params->entries); > uint32_t i; > @@ -105,7 +107,14 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params) > return NULL; > } > > - snprintf(hash_name, sizeof(hash_name), "FBK_%s", params->name); > + if (strlen(params->name) >= RTE_FBK_HASH_NAMESIZE) { > + rte_errno = ENAMETOOLONG; > + return NULL; > + } > + > + /* don't care if hash_name is NULL */ > + int unused __rte_unused; > + unused = asprintf(&hash_name, "FBK_%s", params->name); Does this code handle asprintf() failure correctly? If asprintf() fails and returns -1 with hash_name set to NULL, the subsequent code using hash_name could crash or behave incorrectly. > @@ -170,6 +179,7 @@ rte_fbk_hash_create(const struct rte_fbk_hash_params *params) > > exit: > rte_mcfg_tailq_write_unlock(); > + free(hash_name); Does this code have a memory leak on the success path? The hash_name is allocated with asprintf() but only freed at the exit label, which appears to be used for both success and failure cases.