Re: [libvirt] [PATCH 4/4] qemu: Obtain reference on monConfig

2018-04-09 Thread Marc Hartmayer 
On Mon, Apr 09, 2018 at 04:25 PM +0200, Marc Hartmayer 
 wrote:
> On Fri, Apr 06, 2018 at 06:53 PM +0200, John Ferlan  
> wrote:
>> Because we allow a QEMU_JOB_DESTROY to occur while we're starting
>> up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
>> that a domain destroy operation "wins" the race, calls qemuProcessStop
>> which will free and reinitialize priv->monConfig. Depending on the
>> exact timing either qemuMonitorOpen will be passed a NULL @config
>> variable or it will be using free'd (and possibly reclaimed) memory
>> as the @config parameter - neither of which is good.
>>
>> Resolve this by localizing the @monConfig, taking an extra reference,
>> and then once we get the @vm lock again removing our reference since
>> we are done with it.
>>
>> Signed-off-by: John Ferlan 
>> ---
>>  src/qemu/qemu_process.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
>> index a8dab92dd6..988c6b1537 100644
>> --- a/src/qemu/qemu_process.c
>> +++ b/src/qemu/qemu_process.c
>> @@ -1776,6 +1776,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
>> virDomainObjPtr vm, int asyncJob,
>>  qemuDomainObjPrivatePtr priv = vm->privateData;
>>  qemuMonitorPtr mon = NULL;
>>  unsigned long long timeout = 0;
>> +virDomainChrSourceDefPtr monConfig;
>>
>>  if (qemuSecuritySetDaemonSocketLabel(driver->securityManager, vm->def) 
>> < 0) {
>>  VIR_ERROR(_("Failed to set security context for monitor for %s"),
>> @@ -1794,10 +1795,12 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
>> virDomainObjPtr vm, int asyncJob,
>>  virObjectRef(vm);
>>
>>  ignore_value(virTimeMillisNow(>monStart));
>> +monConfig = priv->monConfig;
>> +virObjectRef(monConfig);
>>  virObjectUnlock(vm);
>>
>>  mon = qemuMonitorOpen(vm,
>> -  priv->monConfig,
>> +  monConfig,
>>priv->monJSON,
>>timeout,
>>,
>> @@ -1813,6 +1816,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
>> virDomainObjPtr vm, int asyncJob,
>>
>>  virObjectLock(vm);
>>  virObjectUnref(vm);
>> +virObjectUnref(monConfig);
>
> Only for consistency: I would first unref @monConfig and then do the
> unref for @vm.

With this change: Reviewed-by: Marc Hartmayer 

>
>>  priv->monStart = 0;
>>
>>  if (!virDomainObjIsActive(vm)) {
>> --
>> 2.13.6
>>
>> --
>> libvir-list mailing list
>> libvir-list@redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
> --
> Beste Grüße / Kind regards
>Marc Hartmayer
>
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz
> Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen
> Registergericht: Amtsgericht Stuttgart, HRB 243294
--
Beste Grüße / Kind regards
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 4/4] qemu: Obtain reference on monConfig

2018-04-09 Thread Marc Hartmayer 
On Fri, Apr 06, 2018 at 06:53 PM +0200, John Ferlan  wrote:
> Because we allow a QEMU_JOB_DESTROY to occur while we're starting
> up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
> that a domain destroy operation "wins" the race, calls qemuProcessStop
> which will free and reinitialize priv->monConfig. Depending on the
> exact timing either qemuMonitorOpen will be passed a NULL @config
> variable or it will be using free'd (and possibly reclaimed) memory
> as the @config parameter - neither of which is good.
>
> Resolve this by localizing the @monConfig, taking an extra reference,
> and then once we get the @vm lock again removing our reference since
> we are done with it.
>
> Signed-off-by: John Ferlan 
> ---
>  src/qemu/qemu_process.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
> index a8dab92dd6..988c6b1537 100644
> --- a/src/qemu/qemu_process.c
> +++ b/src/qemu/qemu_process.c
> @@ -1776,6 +1776,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
> virDomainObjPtr vm, int asyncJob,
>  qemuDomainObjPrivatePtr priv = vm->privateData;
>  qemuMonitorPtr mon = NULL;
>  unsigned long long timeout = 0;
> +virDomainChrSourceDefPtr monConfig;
>
>  if (qemuSecuritySetDaemonSocketLabel(driver->securityManager, vm->def) < 
> 0) {
>  VIR_ERROR(_("Failed to set security context for monitor for %s"),
> @@ -1794,10 +1795,12 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
> virDomainObjPtr vm, int asyncJob,
>  virObjectRef(vm);
>
>  ignore_value(virTimeMillisNow(>monStart));
> +monConfig = priv->monConfig;
> +virObjectRef(monConfig);
>  virObjectUnlock(vm);
>
>  mon = qemuMonitorOpen(vm,
> -  priv->monConfig,
> +  monConfig,
>priv->monJSON,
>timeout,
>,
> @@ -1813,6 +1816,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
> virDomainObjPtr vm, int asyncJob,
>
>  virObjectLock(vm);
>  virObjectUnref(vm);
> +virObjectUnref(monConfig);

Only for consistency: I would first unref @monConfig and then do the
unref for @vm.

>  priv->monStart = 0;
>
>  if (!virDomainObjIsActive(vm)) {
> --
> 2.13.6
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
Beste Grüße / Kind regards
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 4/4] qemu: Obtain reference on monConfig

2018-04-06 Thread John Ferlan 
Because we allow a QEMU_JOB_DESTROY to occur while we're starting
up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
that a domain destroy operation "wins" the race, calls qemuProcessStop
which will free and reinitialize priv->monConfig. Depending on the
exact timing either qemuMonitorOpen will be passed a NULL @config
variable or it will be using free'd (and possibly reclaimed) memory
as the @config parameter - neither of which is good.

Resolve this by localizing the @monConfig, taking an extra reference,
and then once we get the @vm lock again removing our reference since
we are done with it.

Signed-off-by: John Ferlan 
---
 src/qemu/qemu_process.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index a8dab92dd6..988c6b1537 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -1776,6 +1776,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 qemuDomainObjPrivatePtr priv = vm->privateData;
 qemuMonitorPtr mon = NULL;
 unsigned long long timeout = 0;
+virDomainChrSourceDefPtr monConfig;
 
 if (qemuSecuritySetDaemonSocketLabel(driver->securityManager, vm->def) < 
0) {
 VIR_ERROR(_("Failed to set security context for monitor for %s"),
@@ -1794,10 +1795,12 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 virObjectRef(vm);
 
 ignore_value(virTimeMillisNow(>monStart));
+monConfig = priv->monConfig;
+virObjectRef(monConfig);
 virObjectUnlock(vm);
 
 mon = qemuMonitorOpen(vm,
-  priv->monConfig,
+  monConfig,
   priv->monJSON,
   timeout,
   ,
@@ -1813,6 +1816,7 @@ qemuConnectMonitor(virQEMUDriverPtr driver, 
virDomainObjPtr vm, int asyncJob,
 
 virObjectLock(vm);
 virObjectUnref(vm);
+virObjectUnref(monConfig);
 priv->monStart = 0;
 
 if (!virDomainObjIsActive(vm)) {
-- 
2.13.6

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list