[libvirt] [PATCH] qemu: kill some dead stores
Spotted by clang. The qemuConnectMonitor one is an outright bug, the other two are cosmetic. * src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise. (qemuConnectMonitor): Don't lose error status. --- src/qemu/qemu_driver.c | 2 -- src/qemu/qemu_monitor.c | 4 +--- 2 files changed, 1 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 098f4da..57b8271 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) ret = qemuMonitorSetCapabilities(priv->mon); qemuDomainObjExitMonitorWithDriver(driver, vm); - ret = 0; error: if (ret < 0) qemuMonitorClose(priv->mon); @@ -6535,7 +6534,6 @@ qemudDomainSaveImageStartVM(virConnectPtr conn, wait_ret = qemudDomainSaveImageClose(fd, read_pid, &status); fd = -1; if (read_pid != -1) { - read_pid = -1; if (wait_ret == -1) { virReportSystemError(errno, _("failed to wait for process reading '%s'"), diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index f1494ff..2366fdb 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -685,8 +685,6 @@ cleanup: void qemuMonitorClose(qemuMonitorPtr mon) { - int refs; - if (!mon) return; @@ -706,7 +704,7 @@ void qemuMonitorClose(qemuMonitorPtr mon) mon->closed = 1; } - if ((refs = qemuMonitorUnref(mon)) > 0) + if (qemuMonitorUnref(mon) > 0) qemuMonitorUnlock(mon); } -- 1.7.2
On Fri, Jul 30, 2010 at 09:52:47AM -0600, Eric Blake wrote:
Spotted by clang. The qemuConnectMonitor one is an outright bug, the other two are cosmetic.
* src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise. (qemuConnectMonitor): Don't lose error status. --- src/qemu/qemu_driver.c | 2 -- src/qemu/qemu_monitor.c | 4 +--- 2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 098f4da..57b8271 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) ret = qemuMonitorSetCapabilities(priv->mon); qemuDomainObjExitMonitorWithDriver(driver, vm);
- ret = 0; error: if (ret < 0) qemuMonitorClose(priv->mon);
Hum, if we do this we change the behaviour in case of errors in qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid failing in that case, and if this was the case then it's the first affectation we need to remove. I would wait until this gets clarified (qemuMonitorSetCapabilities failure may not be a blocking factor to starting a guest ...)
@@ -6535,7 +6534,6 @@ qemudDomainSaveImageStartVM(virConnectPtr conn, wait_ret = qemudDomainSaveImageClose(fd, read_pid, &status); fd = -1; if (read_pid != -1) { - read_pid = -1; if (wait_ret == -1) { virReportSystemError(errno, _("failed to wait for process reading '%s'"),
this one is fine
diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index f1494ff..2366fdb 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -685,8 +685,6 @@ cleanup:
void qemuMonitorClose(qemuMonitorPtr mon) { - int refs; - if (!mon) return;
@@ -706,7 +704,7 @@ void qemuMonitorClose(qemuMonitorPtr mon) mon->closed = 1; }
- if ((refs = qemuMonitorUnref(mon)) > 0) + if (qemuMonitorUnref(mon) > 0) qemuMonitorUnlock(mon); }
that too obviously, Could you push the 2 last one until we find out for first one ? thanks ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/30/2010 11:09 AM, Daniel Veillard wrote:
On Fri, Jul 30, 2010 at 09:52:47AM -0600, Eric Blake wrote:
Spotted by clang. The qemuConnectMonitor one is an outright bug, the other two are cosmetic.
* src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise. (qemuConnectMonitor): Don't lose error status. --- src/qemu/qemu_driver.c | 2 -- src/qemu/qemu_monitor.c | 4 +--- 2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 098f4da..57b8271 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) ret = qemuMonitorSetCapabilities(priv->mon); qemuDomainObjExitMonitorWithDriver(driver, vm);
- ret = 0; error: if (ret < 0) qemuMonitorClose(priv->mon);
Hum, if we do this we change the behaviour in case of errors in qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid failing in that case, and if this was the case then it's the first affectation we need to remove. I would wait until this gets clarified (qemuMonitorSetCapabilities failure may not be a blocking factor to starting a guest ...)
This bug was was introduced in commit e72cc3c, with dwalsh's patch on May 27. We were doing the correct thing before then, so only 0.8.2 contains a problem where failure to connect to the monitor is undetected.
that too obviously,
Could you push the 2 last one until we find out for first one ?
Yep, I've just split the patch. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Fri, Jul 30, 2010 at 11:11:38AM -0600, Eric Blake wrote:
On 07/30/2010 11:09 AM, Daniel Veillard wrote:
On Fri, Jul 30, 2010 at 09:52:47AM -0600, Eric Blake wrote:
Spotted by clang. The qemuConnectMonitor one is an outright bug, the other two are cosmetic.
* src/qemu/qemu_monitor.c (qemuMonitorClose): Kill dead store. * src/qemu/qemu_driver.c (qemudDomainSaveImageStartVM): Likewise. (qemuConnectMonitor): Don't lose error status. --- src/qemu/qemu_driver.c | 2 -- src/qemu/qemu_monitor.c | 4 +--- 2 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 098f4da..57b8271 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) ret = qemuMonitorSetCapabilities(priv->mon); qemuDomainObjExitMonitorWithDriver(driver, vm);
- ret = 0; error: if (ret < 0) qemuMonitorClose(priv->mon);
Hum, if we do this we change the behaviour in case of errors in qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid failing in that case, and if this was the case then it's the first affectation we need to remove. I would wait until this gets clarified (qemuMonitorSetCapabilities failure may not be a blocking factor to starting a guest ...)
This bug was was introduced in commit e72cc3c, with dwalsh's patch on May 27. We were doing the correct thing before then, so only 0.8.2 contains a problem where failure to connect to the monitor is undetected.
okidoc, ACK, sorry for the burden :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On 07/31/2010 01:52 AM, Daniel Veillard wrote:
@@ -1416,7 +1416,6 @@ qemuConnectMonitor(struct qemud_driver *driver, virDomainObjPtr vm) ret = qemuMonitorSetCapabilities(priv->mon); qemuDomainObjExitMonitorWithDriver(driver, vm);
- ret = 0; error: if (ret < 0) qemuMonitorClose(priv->mon);
Hum, if we do this we change the behaviour in case of errors in qemuMonitorSetCapabilities(), I wonder if this wasn't there to avoid failing in that case, and if this was the case then it's the first affectation we need to remove. I would wait until this gets clarified (qemuMonitorSetCapabilities failure may not be a blocking factor to starting a guest ...)
This bug was was introduced in commit e72cc3c, with dwalsh's patch on May 27. We were doing the correct thing before then, so only 0.8.2 contains a problem where failure to connect to the monitor is undetected.
okidoc, ACK, sorry for the burden :-)
No problem - it was worth it to make me trawl through 'git gui blame', since I learned more about how to effectively use it. Now pushed. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (2)
-
Daniel Veillard -
Eric Blake