Message ID | 1415002313-15661-1-git-send-email-changchun.ouyang@intel.com (mailing list archive) |
---|---|
State | Accepted, archived |
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [IPv6:::1]) by dpdk.org (Postfix) with ESMTP id CABE45917; Mon, 3 Nov 2014 09:03:10 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 4A50A5917 for <dev@dpdk.org>; Mon, 3 Nov 2014 09:03:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 03 Nov 2014 00:05:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="410243809" Received: from shvmail01.sh.intel.com ([10.239.29.42]) by FMSMGA003.fm.intel.com with ESMTP; 03 Nov 2014 00:03:40 -0800 Received: from shecgisg004.sh.intel.com (shecgisg004.sh.intel.com [10.239.29.89]) by shvmail01.sh.intel.com with ESMTP id sA38C1nZ029552; Mon, 3 Nov 2014 16:12:01 +0800 Received: from shecgisg004.sh.intel.com (localhost [127.0.0.1]) by shecgisg004.sh.intel.com (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id sA38Bx8r015694; Mon, 3 Nov 2014 16:12:01 +0800 Received: (from couyang@localhost) by shecgisg004.sh.intel.com (8.13.6/8.13.6/Submit) id sA38BtPC015690; Mon, 3 Nov 2014 16:11:55 +0800 From: Ouyang Changchun <changchun.ouyang@intel.com> To: dev@dpdk.org Date: Mon, 3 Nov 2014 16:11:53 +0800 Message-Id: <1415002313-15661-1-git-send-email-changchun.ouyang@intel.com> X-Mailer: git-send-email 1.7.12.2 Subject: [dpdk-dev] [PATCH] librte_vhost: Fix the path test issue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Commit Message
Ouyang Changchun
Nov. 3, 2014, 8:11 a.m. UTC
Commit aec8283d47d4e4366b6 fixes the compilation issue, but it leads to
one runtime issue: early exit wrongly. In some case, 'path' is NULL, but
'resolved_path' has effective path, it should continue going ahead rather
than exit.
Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com>
---
lib/librte_vhost/virtio-net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
> path = realpath(memfile, resolved_path); > - if (path == NULL) { > + if ((path == NULL) && (strlen(resolved_path) == 0)) { > RTE_LOG(ERR, VHOST_CONFIG, > "(%"PRIu64") Failed to resolve fd directory\n", > dev->device_fh); Changchun: For some strange file, according to API description, we shouldn't check resolved_path as it is undefined. To make the loop go on, we could use "continue" when we detect path is NULL. RETURN VALUE If there is no error, realpath() returns a pointer to the resolved_path. Otherwise it returns a NULL pointer, and the contents of the array resolved_path are undefined, and errno is set to indicate the error.
Hi Huawei, Thanks for the comments, And my response as follows. > -----Original Message----- > From: Xie, Huawei > Sent: Thursday, November 6, 2014 10:39 AM > To: Ouyang, Changchun; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH] librte_vhost: Fix the path test issue > > > path = realpath(memfile, resolved_path); > > - if (path == NULL) { > > + if ((path == NULL) && (strlen(resolved_path) == 0)) { > > RTE_LOG(ERR, VHOST_CONFIG, > > "(%"PRIu64") Failed to resolve fd directory\n", > > dev->device_fh); > Changchun: > For some strange file, according to API description, we shouldn't check > resolved_path as it is undefined. > To make the loop go on, we could use "continue" when we detect path is > NULL. > > RETURN VALUE > If there is no error, realpath() returns a pointer to the resolved_path. > > Otherwise it returns a NULL pointer, and the contents of the array > resolved_path are undefined, and errno is set to indicate the error. After my investigation this issue and find out using continue doesn't work. The reason is procmap.fname itself is "/dev/hugepages/qemu_back_mem.pc.ram.zxfqLq", It is not a normal path, so in this case, path is null, while resolved-path is /dev/hugepages/qemu_back_mem.pc.ram.zxfqLq If 'continue' is used, then procmap.fname could not be hit in the directory list, And then app will exit after report: Failed to find memory file for pid.... So I have to keep it. Thanks again Changchun
> -----Original Message----- > From: Ouyang, Changchun > Sent: Wednesday, November 05, 2014 10:20 PM > To: Xie, Huawei; dev@dpdk.org > Cc: Ouyang, Changchun > Subject: RE: [dpdk-dev] [PATCH] librte_vhost: Fix the path test issue > > Hi Huawei, > Thanks for the comments, > And my response as follows. > > > -----Original Message----- > > From: Xie, Huawei > > Sent: Thursday, November 6, 2014 10:39 AM > > To: Ouyang, Changchun; dev@dpdk.org > > Subject: RE: [dpdk-dev] [PATCH] librte_vhost: Fix the path test issue > > > > > path = realpath(memfile, resolved_path); > > > - if (path == NULL) { > > > + if ((path == NULL) && (strlen(resolved_path) == 0)) { > > > RTE_LOG(ERR, VHOST_CONFIG, > > > "(%"PRIu64") Failed to resolve fd directory\n", > > > dev->device_fh); > > Changchun: > > For some strange file, according to API description, we shouldn't check > > resolved_path as it is undefined. > > To make the loop go on, we could use "continue" when we detect path is > > NULL. > > > > RETURN VALUE > > If there is no error, realpath() returns a pointer to the resolved_path. > > > > Otherwise it returns a NULL pointer, and the contents of the array > > resolved_path are undefined, and errno is set to indicate the error. > > After my investigation this issue and find out using continue doesn't work. > > The reason is procmap.fname itself is > "/dev/hugepages/qemu_back_mem.pc.ram.zxfqLq", > It is not a normal path, so in this case, path is null, while resolved-path is > /dev/hugepages/qemu_back_mem.pc.ram.zxfqLq > > If 'continue' is used, then procmap.fname could not be hit in the directory list, > And then app will exit after report: Failed to find memory file for pid.... I did some investigation. This is due to that qemu unlink the file after it maps the huge page file. So this is a special case, it is ok we check the resolved path when path is NULL if errno indicates "No such file or directory". > > So I have to keep it. > > Thanks again > Changchun
> -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ouyang Changchun > Sent: Monday, November 03, 2014 1:12 AM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH] librte_vhost: Fix the path test issue > > Commit aec8283d47d4e4366b6 fixes the compilation issue, but it leads to > one runtime issue: early exit wrongly. In some case, 'path' is NULL, but > 'resolved_path' has effective path, it should continue going ahead rather > than exit. > > Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com> > --- > lib/librte_vhost/virtio-net.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c > index 8015dd8..3fa1274 100644 > --- a/lib/librte_vhost/virtio-net.c > +++ b/lib/librte_vhost/virtio-net.c > @@ -237,7 +237,7 @@ host_memory_map(struct virtio_net *dev, struct > virtio_memory *mem, > snprintf(memfile, PATH_MAX, "/proc/%u/fd/%s", > pid, dptr->d_name); > path = realpath(memfile, resolved_path); > - if (path == NULL) { > + if ((path == NULL) && (strlen(resolved_path) == 0)) { > RTE_LOG(ERR, VHOST_CONFIG, > "(%"PRIu64") Failed to resolve fd directory\n", > dev->device_fh); > -- > 1.8.4.2 Acked-by: Huawei Xie <huawei.xie@intel.com>
> > Commit aec8283d47d4e4366b6 fixes the compilation issue, but it leads to > > one runtime issue: early exit wrongly. In some case, 'path' is NULL, but > > 'resolved_path' has effective path, it should continue going ahead rather > > than exit. > > > > Signed-off-by: Changchun Ouyang <changchun.ouyang@intel.com> > > Acked-by: Huawei Xie <huawei.xie@intel.com> Applied with Huawei's explanation. Thanks
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c index 8015dd8..3fa1274 100644 --- a/lib/librte_vhost/virtio-net.c +++ b/lib/librte_vhost/virtio-net.c @@ -237,7 +237,7 @@ host_memory_map(struct virtio_net *dev, struct virtio_memory *mem, snprintf(memfile, PATH_MAX, "/proc/%u/fd/%s", pid, dptr->d_name); path = realpath(memfile, resolved_path); - if (path == NULL) { + if ((path == NULL) && (strlen(resolved_path) == 0)) { RTE_LOG(ERR, VHOST_CONFIG, "(%"PRIu64") Failed to resolve fd directory\n", dev->device_fh);