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 6CEBAA00C5; Tue, 15 Feb 2022 11:59:30 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32F87410F3; Tue, 15 Feb 2022 11:59:30 +0100 (CET) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id 151DC40E78 for ; Tue, 15 Feb 2022 11:59:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644922768; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3P/NUu+AIzZ7jsKdkq20Pt3XviZI5t1Vt+IBrzxjkQc=; b=SerMoP5Eaq1zBNU377DHnvyoYMK+wXshkDhLizG6Ro2wGHHQdhRHjTRZ01bqHsrtCCXSE9 0BzYQqMUrS7Vo6QUusftIATm0GUBhoGguw0nncHyxtia11TtBT0ULXVcuPdBQKo9aBkVI+ qQqCwkFXJ3hIalRlwnuXpjB8bjMZfM0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-247-Z9_cpsx1MziVOjOaIvx8JA-1; Tue, 15 Feb 2022 05:59:25 -0500 X-MC-Unique: Z9_cpsx1MziVOjOaIvx8JA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 038BA2F25; Tue, 15 Feb 2022 10:59:24 +0000 (UTC) Received: from [10.39.208.17] (unknown [10.39.208.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E9AB178DE9; Tue, 15 Feb 2022 10:59:21 +0000 (UTC) Message-ID: <98a89ac3-48b4-c368-fa47-454880c7841a@redhat.com> Date: Tue, 15 Feb 2022 11:59:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v3] vdpa/sfc: make MCDI memzone name unique From: Maxime Coquelin To: abhimanyu.saini@xilinx.com, dev@dpdk.org Cc: chenbo.xia@intel.com, andrew.rybchenko@oktetlabs.ru, Abhimanyu Saini References: <20220117112906.23823-1-asaini@xilinx.com> <20220214105148.18414-1-asaini@xilinx.com> <07f7dd4f-34b3-8b61-46f7-ab183703e92b@redhat.com> In-Reply-To: <07f7dd4f-34b3-8b61-46f7-ab183703e92b@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=maxime.coquelin@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 2/15/22 11:56, Maxime Coquelin wrote: > > > On 2/14/22 11:51, abhimanyu.saini@xilinx.com wrote: >> From: Abhimanyu Saini >> >> Buffer for MCDI channel is allocated using rte_memzone_reserve_aligned >> with zone name 'mcdi'. Since multiple MCDI channels are needed to >> support multiple VF(s) and rte_memzone_reserve_aligned expects unique >> zone names, append PCI address to zone name to make it unique. >> >> Signed-off-by: Abhimanyu Saini >> --- >> v2: >>    - Formatting changes >> v3: >>    - Formatting changes >> >>   drivers/vdpa/sfc/sfc_vdpa_hw.c | 15 ++++++++++++--- >>   1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/vdpa/sfc/sfc_vdpa_hw.c >> b/drivers/vdpa/sfc/sfc_vdpa_hw.c >> index fd1fee7..a7018b1 100644 >> --- a/drivers/vdpa/sfc/sfc_vdpa_hw.c >> +++ b/drivers/vdpa/sfc/sfc_vdpa_hw.c >> @@ -25,21 +25,30 @@ >>   { >>       uint64_t mcdi_iova; >>       size_t mcdi_buff_size; >> +    char mz_name[RTE_MEMZONE_NAMESIZE]; >>       const struct rte_memzone *mz = NULL; >>       int numa_node = sva->pdev->device.numa_node; >>       int ret; >>       mcdi_buff_size = RTE_ALIGN_CEIL(len, PAGE_SIZE); >> +    ret = snprintf(mz_name, RTE_MEMZONE_NAMESIZE, "%s_%s", >> +               sva->pdev->name, name); >> +    if (ret < 0 || ret >= RTE_MEMZONE_NAMESIZE) { > > From the man page: > " > The functions snprintf() and vsnprintf() do not write more than size > bytes (including the terminating null byte ('\0')). > " > > you might want to pass RTE_MEMZONE_NAMESIZE - 1 as size arg to snprintf, > so you can just check ret >= 0? Sorry, I misread, the return value can indeed be greater than size: " If the output was truncated due to this limit, then the return value is the number of characters (excluding the terminating null byte) which would have been written to the final string if enough space had been available. Thus, a return value of size or more means that the output was truncated. " >> +        sfc_vdpa_err(sva, "%s_%s too long to fit in mz_name", >> +                 sva->pdev->name, name); >> +        return -EINVAL; >> +    } >> -    sfc_vdpa_log_init(sva, "name=%s, len=%zu", name, len); >> +    sfc_vdpa_log_init(sva, "name=%s, len=%zu", mz_name, len); >> -    mz = rte_memzone_reserve_aligned(name, mcdi_buff_size, >> +    mz = rte_memzone_reserve_aligned(mz_name, mcdi_buff_size, >>                        numa_node, >>                        RTE_MEMZONE_IOVA_CONTIG, >>                        PAGE_SIZE); >>       if (mz == NULL) { >>           sfc_vdpa_err(sva, "cannot reserve memory for %s: len=%#x: %s", >> -                 name, (unsigned int)len, rte_strerror(rte_errno)); >> +                 mz_name, (unsigned int)len, >> +                 rte_strerror(rte_errno)); >>           return -ENOMEM; >>       }