[libvirt] [PATCH] qemu: Make virFileFindHugeTLBFS fault tolerant
Since commit be0782e1 we are parsing /proc/meminfo to find out the default huge page size. However, if the host we are running at does not support any huge pages (e.g. CONFIG_HUGETLB_PAGE is turned off), we will not successfully parse the meminfo file and hence the whole qemu driver init process fails. Moreover, the default huge page size is needed if and only if there's at least one hugetlbfs mount point. So the fix consists of moving the virFileGetDefaultHugepageSize function call after the first hugetlbfs mount point is found. With this fix, we fail to start with one or more hugetlbfs mounts and malformed meminfo file, but that's expected (how can one mount hugetlbfs without kernel supporting huge pages?). Workaround in that case is to umount all the hugetlbfs mounts. Reported-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/util/virfile.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/util/virfile.c b/src/util/virfile.c index 9863fd0..f9efc65 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -2990,10 +2990,7 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, char mntbuf[1024]; virHugeTLBFSPtr fs = NULL; size_t nfs = 0; - unsigned long long default_hugepagesz; - - if (virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) - goto cleanup; + unsigned long long default_hugepagesz = 0; if (!(f = setmntent(PROC_MOUNTS, "r"))) { virReportSystemError(errno, @@ -3019,6 +3016,10 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, if (virFileGetHugepageSize(tmp->mnt_dir, &tmp->size) < 0) goto cleanup; + if (!default_hugepagesz && + virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) + goto cleanup; + tmp->deflt = tmp->size == default_hugepagesz; } -- 1.8.5.5
On Wed, Aug 06, 2014 at 10:44:55AM +0200, Michal Privoznik wrote:
Since commit be0782e1 we are parsing /proc/meminfo to find out the default huge page size. However, if the host we are running at does not support any huge pages (e.g. CONFIG_HUGETLB_PAGE is turned off), we will not successfully parse the meminfo file and hence the whole qemu driver init process fails. Moreover, the default huge page size is needed if and only if there's at least one hugetlbfs mount point. So the fix consists of moving the virFileGetDefaultHugepageSize function call after the first hugetlbfs mount point is found.
With this fix, we fail to start with one or more hugetlbfs mounts and malformed meminfo file, but that's expected (how can one mount hugetlbfs without kernel supporting huge pages?). Workaround in that case is to umount all the hugetlbfs mounts.
Reported-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/util/virfile.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
ACK, Martin
diff --git a/src/util/virfile.c b/src/util/virfile.c index 9863fd0..f9efc65 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -2990,10 +2990,7 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, char mntbuf[1024]; virHugeTLBFSPtr fs = NULL; size_t nfs = 0; - unsigned long long default_hugepagesz; - - if (virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) - goto cleanup; + unsigned long long default_hugepagesz = 0;
if (!(f = setmntent(PROC_MOUNTS, "r"))) { virReportSystemError(errno, @@ -3019,6 +3016,10 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, if (virFileGetHugepageSize(tmp->mnt_dir, &tmp->size) < 0) goto cleanup;
+ if (!default_hugepagesz && + virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) + goto cleanup; + tmp->deflt = tmp->size == default_hugepagesz; }
-- 1.8.5.5
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Michal Privoznik wrote:
Since commit be0782e1 we are parsing /proc/meminfo to find out the default huge page size. However, if the host we are running at does not support any huge pages (e.g. CONFIG_HUGETLB_PAGE is turned off), we will not successfully parse the meminfo file and hence the whole qemu driver init process fails. Moreover, the default huge page size is needed if and only if there's at least one hugetlbfs mount point. So the fix consists of moving the virFileGetDefaultHugepageSize function call after the first hugetlbfs mount point is found.
With this fix, we fail to start with one or more hugetlbfs mounts and malformed meminfo file, but that's expected (how can one mount hugetlbfs without kernel supporting huge pages?). Workaround in that case is to umount all the hugetlbfs mounts.
Makes sense.
Reported-by: Jim Fehlig <jfehlig@suse.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> --- src/util/virfile.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/util/virfile.c b/src/util/virfile.c index 9863fd0..f9efc65 100644 --- a/src/util/virfile.c +++ b/src/util/virfile.c @@ -2990,10 +2990,7 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, char mntbuf[1024]; virHugeTLBFSPtr fs = NULL; size_t nfs = 0; - unsigned long long default_hugepagesz; - - if (virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) - goto cleanup; + unsigned long long default_hugepagesz = 0;
if (!(f = setmntent(PROC_MOUNTS, "r"))) { virReportSystemError(errno, @@ -3019,6 +3016,10 @@ virFileFindHugeTLBFS(virHugeTLBFSPtr *ret_fs, if (virFileGetHugepageSize(tmp->mnt_dir, &tmp->size) < 0) goto cleanup;
+ if (!default_hugepagesz && + virFileGetDefaultHugepageSize(&default_hugepagesz) < 0) + goto cleanup; + tmp->deflt = tmp->size == default_hugepagesz; }
And it fixes the issue for me, thanks! ACK #2 :-). Regards, Jim
participants (3)
-
Jim Fehlig -
Martin Kletzander -
Michal Privoznik