From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) by dpdk.org (Postfix) with ESMTP id 5F4B51B457 for ; Mon, 7 Jan 2019 17:18:01 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 9CBA38006B; Mon, 7 Jan 2019 16:17:59 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 7 Jan 2019 16:17:51 +0000 To: Stephen Hemminger CC: Nithin Kumar Dabilpuram , Thomas Monjalon , Ferruh Yigit , "dev@dpdk.org" , Jerin Jacob Kollanukkaran References: <20190107143951.30076-1-ndabilpuram@marvell.com> <20190107075332.1301e617@hermes.lan> From: Andrew Rybchenko Message-ID: <5ec7cf71-9d90-3d07-f41c-ae486264620c@solarflare.com> Date: Mon, 7 Jan 2019 19:17:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190107075332.1301e617@hermes.lan> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24342.003 X-TM-AS-Result: No-20.857000-8.000000-10 X-TMASE-MatchedRID: VfovoVrt/oYOwH4pD14DsPHkpkyUphL9GZjaqakC/MbfUZT83lbkELxM KamuTJuMS9SYqwQd7qi2q4RAeMRmGTbGo3kv6hASyeVujmXuYYUpWss5kPUFdKTBJ7MPLLGut+q ic3JQJX0wfXkTrrUIE7WT4oYlbXTBSOWjYlTyoLH9vE/QVDV5IXzIY7d2+Tz9AnW+Tu2Fi4ZR18 QpzXStTi9BUTTI4YWlioFl5UK3cJ/SduMc6RnI+T5bo3ZLMFMHB+dff70WbjlCI7pNLiSjfcUzz dIu4oxh92grUwQgYZd5OPD8XJFfpE1+zyfzlN7ygxsfzkNRlfKx5amWK2anSEUYJ3RLQ0Ky9CGG ZQkH3kv+sTDZBRrKjEOvZQOOrhKEavznBy1mj4gchXTZ3Wukbw== X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--20.857000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24342.003 X-MDID: 1546877880-jhFGxjOrwRbr Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH] ethdev: report error on name truncation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 16:18:01 -0000 On 1/7/19 6:53 PM, Stephen Hemminger wrote: > On Mon, 7 Jan 2019 17:47:08 +0300 > Andrew Rybchenko wrote: > >> On 1/7/19 5:40 PM, Nithin Kumar Dabilpuram wrote: >>> Signed-off-by: Nithin Dabilpuram >>> --- >>> lib/librte_ethdev/rte_ethdev.c | 12 ++++++++++-- >>> 1 file changed, 10 insertions(+), 2 deletions(-) >>> >>> diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c >>> index 9d5107d..bd45445 100644 >>> --- a/lib/librte_ethdev/rte_ethdev.c >>> +++ b/lib/librte_ethdev/rte_ethdev.c >>> @@ -3588,9 +3588,17 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev *dev, const char *ring_name, >>> { >>> char z_name[RTE_MEMZONE_NAMESIZE]; >>> const struct rte_memzone *mz; >>> + int rc; >>> >>> - snprintf(z_name, sizeof(z_name), "eth_p%d_q%d_%s", >>> - dev->data->port_id, queue_id, ring_name); >>> + rc = snprintf(z_name, sizeof(z_name), "%s_%s_%d_%d", >>> + dev->device->driver->name, ring_name, >>> + dev->data->port_id, queue_id); >>> + >>> + if (rc >= RTE_MEMZONE_NAMESIZE) { >>> + RTE_LOG(ERR, EAL, "%s(): truncated name\n", __func__); >>> + rte_errno = ENAMETOOLONG; >>> + return NULL; >>> + } >>> >>> mz = rte_memzone_lookup(z_name); >>> if (mz) >> It is good to report an error in the case of name truncation, but the patch >> does more. It changes format of the memzone name, adds the driver name >> in it (what is bad since testpmd has commands to find the memzone by name >> and read descriptors (hack, but sometimes very useful)). >> Also I'm not sure about function name in the log message. Other places >> do not have it. >> > Maybe MEMZONE_NAMESIZE should be big enough that this should never happen? > The size is arbitrary anyway. ring_name is provided by caller, so we can't guarantee it locally.