These functions are all only called as a part of qemuFirmwareFree(),
which frees the qemuFirmware object before return, so we can be sure
none of the pointers is referenced after freeing (and thus there is no
need to clear any of them).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
These functions all cooperate to free memory pointed to by a single
object that contains (doesn't *point to*, but actually contains)
several sub-objects. They were written to send copies of these
sub-objects to subordinate functions, rather than just sending
pointers to the sub-objects.
Let's change these functions to just send pointers to the objects
they're cleaning out rather than all the wasteful and pointless
copying.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Several functions had the names virFirmware[something]Free(), but they
aren't taking a pointer to some object and freeing it. Instead, they
are making a copy of the content of an entire object, then Freeing the
objects pointed to by that content.
As a first step in a too-complicated cleanup just to eliminate a few
occurrences of VIR_FREE(), this patch renames those functions to more
accurately reflect what they do - they Free the *Content* of their
arguments.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
dhcpHostFree() and addnHostFree() don't follow the normal pattern of
*Free functions in the rest of libvirt code - they are actually more
similar to the *Dispose() functions, in that they free all subordinate
objects, but not the object pointed to by the argument
itself. However, the arguments aren't virObjects, so it wouldn't be
proper to name them *Dispose() either.
They *currently* behave similar to a *Clear() function, in that they
free all the subordinate objects and nullify the pointers of those
objects. HOWEVER, we don't actually need or want that behavior - the
two functions in question are only called as part of a higher level
*Free() function, and the pointers are not referenced in any way
between the time they are freed and when the parent object is freed.
So, since the current name isn't correct, nor is *Dispose(), and we
want to change the behavior in such a way that *Clear() also wouldn't
be correct, lets name the functions *FreeContent(), which is an
accurate description of what the functions do, and what we *want* them
to do.
And since it's such a small patch, we can go ahead and change that
behavior - replacing the VIR_FREEs with g_free.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Commit <318d807a0bd3372b634d1952b559c5c627ccfa5b> added a fix to skip
most of the block stat code to not log error message for missing storage
sources but forgot to increase the recordnr counter.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The correct backend type is 'vc', same as in qemuBuildChrChardevStr()
where we generate qemu command line.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A memory leak was identified in
virCgroupEnableMissingControllers():
==11680== at 0x483EAE5: calloc (vg_replace_malloc.c:760)
==11680== by 0x4E51780: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6701.0)
==11680== by 0x4908618: virCgroupNew (vircgroup.c:701)
==11680== by 0x49096F4: virCgroupEnableMissingControllers (vircgroup.c:1146)
==11680== by 0x4909B17: virCgroupNewMachineSystemd (vircgroup.c:1228)
==11680== by 0x4909E94: virCgroupNewMachine (vircgroup.c:1313)
==11680== by 0x1694FDBC: qemuInitCgroup (qemu_cgroup.c:946)
==11680== by 0x1695046B: qemuSetupCgroup (qemu_cgroup.c:1083)
==11680== by 0x16A60126: qemuProcessLaunch (qemu_process.c:7077)
==11680== by 0x16A61504: qemuProcessStart (qemu_process.c:7384)
==11680== by 0x169B84C2: qemuDomainObjStart (qemu_driver.c:6590)
==11680== by 0x169B8776: qemuDomainCreateWithFlags (qemu_driver.c:6641)
What happens is that new virCgroup is created and stored into
@parent. Then, if @tokens is not empty the for() loop is entered
into where another virCgroup is created and @parent is replaced
with this new virCgroup. But nothing freed the old @parent.
Fixes: 77291414c7a8745cf4d2b06d3c38d269cfbcfe32
Reported-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Implements QEMU support for vhost-user-blk together with live
hotplug/unplug.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Make the function reusable by other vhost-user based devices.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Hypervisors are capable of reporting that some features are deprecated.
This should be used to mark a domain as tainted.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has the ability to mark machine types as deprecated. This should be
exposed to management applications in the capabilities.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU has the ability to mark CPUs as deprecated. This should be exposed
to management applications in the domain capabilities.
This attribute is only set when the model is actually deprecated.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The use case VIR_ALLOC_VAR deals with is very unlikely. We had just 2
legitimate uses, which were reimplemented locally using g_malloc0 and
sizeof instead as they used a static number of members of the trailing
array.
Remove VIR_ALLOC_VAR since in most cases the direct implementation is
shorter and clearer and there are no users of it currently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In this case we need a 'struct ethtool_gfeatures' followed by two
'struct ethtool_get_features_block' so there's no risk of overflow.
Use g_malloc0 and sizeof() to allocate the memory instead of
VIR_ALLOC_VAR.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In both cases we need memory for a 'struct sanlk_resource' followed by
one 'struct sanlk_disk', thus there's no risk of overflow.
Use g_malloc0 and sizeof() to allocate the memory instead of
VIR_ALLOC_VAR.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Use g_autofree to allow removal of 'cleanup:' and the 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Use g_autofree and remove the 'cleanup' section and 'ret' variable.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Switch to the more common approach of having arrays allocated separately
rather than trailing the struct.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Users were replaced with virSecureEraseString with explicit freeing of
the memory.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are no users any more. The replacement is to use g_auto and
virSecureEraseString explicitly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
In this instance attempting to be correct is really pointless since the
secret is formatted into another string which is not erased securely and
then put on the commandline.
Keep the secure handling for correctness.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The macros are unused now and callers who care about clearing the memory
they use should use memset() appropriately.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
