From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 68C9EA04C0; Thu, 17 Sep 2020 16:41:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D28A61D673; Thu, 17 Sep 2020 16:41:21 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 4F4A71D672; Thu, 17 Sep 2020 16:41:20 +0200 (CEST) IronPort-SDR: NIvC61usi5dg1bxlwPyfdhJ90Ort2YRgYdW4hNuzgny141oh4WPX45Ggakytlb+n3RGk67LzWA 8U2BfBaOvtXw== X-IronPort-AV: E=McAfee;i="6000,8403,9747"; a="157095007" X-IronPort-AV: E=Sophos;i="5.77,437,1596524400"; d="scan'208";a="157095007" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 07:41:17 -0700 IronPort-SDR: CNRc/5FkuTOIA6MMFj5BY2T/2RW73tb0IX4hTKvE3hcXrAu6PG7xN+oRJXY0237DpNjnUfXAbQ JyBTcX3rS5Gw== X-IronPort-AV: E=Sophos;i="5.77,437,1596524400"; d="scan'208";a="452329554" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.206.43]) ([10.213.206.43]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Sep 2020 07:41:16 -0700 To: wangyunjian , "dev@dpdk.org" Cc: "hemant.agrawal@nxp.com" , "sachin.saxena@nxp.com" , "Lilijun (Jerry)" , xudingke , "stable@dpdk.org" References: <1589859732-5008-1-git-send-email-wangyunjian@huawei.com> <302a5cfb-f50e-ff66-3267-551fe7a4b6a8@intel.com> <34EFBCA9F01B0748BEB6B629CE643AE60DA5153C@DGGEMM533-MBX.china.huawei.com> From: "Burakov, Anatoly" Message-ID: <0fe98b51-11b4-ec67-3474-544ea783687e@intel.com> Date: Thu, 17 Sep 2020 15:41:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <34EFBCA9F01B0748BEB6B629CE643AE60DA5153C@DGGEMM533-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] bus/fslmc: fix check for vfio_group_fd 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 17-Sep-20 2:34 PM, wangyunjian wrote: >> -----Original Message----- >> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com] >> Sent: Thursday, September 17, 2020 8:56 PM >> To: wangyunjian ; dev@dpdk.org >> Cc: hemant.agrawal@nxp.com; sachin.saxena@nxp.com; Lilijun (Jerry) >> ; xudingke ; >> stable@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 2/2] bus/fslmc: fix check for vfio_group_fd >> >> On 19-May-20 4:42 AM, wangyunjian wrote: >>> From: Yunjian Wang >>> >>> The issue is that a file descriptor at 0 is a valid one. Currently the >>> file not found, the return value will be set to 0. As a result, it is >>> impossible to distinguish between a correct descriptor and a failed >>> return value. Fix it to return -ENOENT instead of 0. >>> >>> Fixes: a69f79300262 ("bus/fslmc: support multi VFIO group") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Yunjian Wang >>> --- >> >> I am unfamiliar with bus/fslmc code but i've taken a quick look, and i've noticed >> that there's another instance of get_group_fd() usage that you're not >> modifying - is that intentional? > > Thank you for your review. The another instance of get_group_fd(), is this it? > int > fslmc_vfio_setup_group(void) { > ... > /* Get the actual group fd */ > ret = rte_vfio_get_group_fd(groupid); > if (ret < 0) > return ret; > vfio_group.fd = ret; > ... > } > I don't think this's necessary. Because it must be a valid descriptor before it can be used. > > Yunjian > >> >> -- >> Thanks, >> Anatoly OK. I'll leave this for fslmc bus maintainers to review, but the patch looks fine to me. Acked-by: Anatoly Burakov -- Thanks, Anatoly