On 11/6/18 7:48 AM, Michal Privoznik wrote: > On 11/06/2018 01:28 PM, John Ferlan wrote: >> >> >> On 11/6/18 4:38 AM, Michal Privoznik wrote: >>> On 11/01/2018 05:04 PM, John Ferlan wrote: >>>> Checking and setting the priv->allowReboot can be done before we start >>>> processing the job. A subsequent patch will make use of the value to >>>> make decisions in the error label, so we need to have it set properly. >>>> >>>> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> >>>> --- >>>> src/qemu/qemu_process.c | 8 ++++---- >>>> 1 file changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c >>>> index 9cf971808c..5232f761af 100644 >>>> --- a/src/qemu/qemu_process.c >>>> +++ b/src/qemu/qemu_process.c >>>> @@ -7767,6 +7767,10 @@ qemuProcessReconnect(void *opaque) >>>> cfg = virQEMUDriverGetConfig(driver); >>>> priv = obj->privateData; >>>> >>>> + /* If we are connecting to a guest started by old libvirt there is no >>>> + * allowReboot in status XML and we need to initialize it. */ >>>> + qemuProcessPrepareAllowReboot(obj); >>> >>> I'm not quite sure why this happens outside of job. It doesn't look like >>> it has to. >>> >> >> Is there a reason in your opinion it needs to occur inside a job? It is >> a void function. > > The type of the return value doesn't matter. > qemuProcessPrepareAllowReboot() changes private data and that is > potentially dangerous if done outside modify job (even though the @vm is > locked at this point so I guess it is not that dangerous after all). > Does that mean we need to cull the code looking for everywhere in the code where @priv data is modified outside a job? and start a job if so? I thought jobs were more related to monitor interactions rather than @priv modification. The answer still doesn't make sense to me. John >> >> It's moved to prior to the first "goto error" because of patch3 which >> would call qemuDomainIsUsingNoShutdown which checks priv->allowReboot >> which is possibly set in *AllowReboot. Without that move, the code would >> need to be reworked, which is fine, but understanding the reason why I >> wrote things the way I did is important, IMO. I can add a comment to >> "warn" the next person trying to move it that the error: logic uses the >> ->allowReboot value. >> >> The allowReboot alteration has nothing to do with a job AFAICT and >> whether on error: there is a job or not. Perhaps no different to what >> qemuDomainObjRestoreJob is doing by using @priv fields for @oldjob. > > Yeah, but RestoreJob is special - we can't call it after job is > acquired, we want to save currently running job to a temp variable so > that we can start a new job. > >> >> Although looking at and quickly thinking about the code now, I wonder if >> the virQEMUDriverGetCapabilities and goto error should be inside a job >> too since error would then call qemuProcessStop without being in a job. > > Ooops, yes. > >> >> If this is dropped then logic in patch3 needs to be altered in order to >> account for jobStarted = true... I think that got too messy when I first >> thought about it. > > Michal > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
