virDomainCapsDispose() was the only caller of
virDomainCapsStringValuesFree(), which 1) didn't actually free the
object it was called with, but only cleared it, making it less
mechanical to convert from VIR_FREE to g_free (since it's not
immediately obvious from looking at virDomainCapsStringValuesFree()
that the pointers being cleared will never again be used).
We could have renamed the function to virDomainCapsStringValuesClear()
to side-step the confusion of what the function actually does, but
that would just make the upcoming switch from VIR_FREE to g_free
require more thought. But since there is only a single caller to the
function, and it is a vir*Dispose() function (indicating that the
object containing the virDomainCapsStringValues is going to be freed
immediately after the function finishes), and thus VIR_FREE() *could*
be safely replaced by g_free()), we instead just move the contents of
virDomainCapsStringValuesFree() into virDomainCapsDispose() (and
*that* function will be trivially converted in an upcoming
"mechanical" patch).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
This is another *Free() function that doesn't free the object it is
passed. Instead it frees and clears some parts of the object.
In this case, the function is actually called from two places, and one
of them (virNetSSHSessionAuthReset) appears to be assuming that the
pointers actually *will* be cleared. So the proper thing to do here
(?) is to rename the function to virNetSSHSesionAuthMethodsClear().
(NB: virNetSSHSessionAuthReset is seemingly never called from
anywhere. Is this one of those functions that actually *is* called by
some strange MACRO invocation? Or it is truly one of those
"written-but-never-used" functions that can be deleted? (if the latter
is the case, then I would rather move the contents of
virNetSessionAuthMethodsFree() into its only other caller,
virNetSSHSessionDispose(), so that the VIR_FREEs could be replaced
with g_free.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
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: 77291414c7
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>
Clear out the value using virSecureErase and free it with g_free so
that VIR_DISPOSE_N can be phased out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Clear the key and IV structs using virSecureErase.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Clear out the value using virSecureErase and free it with g_free so
that VIR_DISPOSE_N can be phased out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Switch the secret value to 'g_autofree' for handling of the memory and
clear it out using virSecureErase.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Phase out use of VIR_DISPOSE_N from the qemu driver. Use memset in the
appropriate cases.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Clear the secret right after use with virSecureErase.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The code pretends that it cares about clearing the secret values, but
passes the secret value to a realloc, which may copy the value somewhere
else and doesn't sanitize the original location when it does so.
Since we want to construct a string from the value, let's copy it to a
new piece of memory which has the space for the 'NUL' byte ourselves, to
prevent a random realloc keeping the data around.
While at it, use virSecureErase instead of VIR_DISPOSE_N since it's
being phased out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The module will provide functions for disposing secrets stored in
memory.
Note that for now it's implemented using memset, which is not really
secure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Shuffle the code around to remove the need for temporary variables and
labels for cleaning them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The check whether @keyfile is non-NULL is before locking @sess, but uses
the 'error' label which unlocks '@sess'.
While touching the error path, update the error message to be on one
line.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When virRandomBytes fails we don't get any random bytes and even if we
did they don't have to be treated as secret as they weren't used in any
way.
Add a temporary variable with automatic freeing for the secret buffer
and assign it only on success.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The list isn't secret which would need being disposed of. Just expand
the array and return failure when adding the NULL terminator similarly
to how we expand the list for adding devices in a loop.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The struct doesn't contain any secrets to clear before freeing and even
if it did VIR_DISPOSE_N wouldn't help as the struct contains only
pointers thus the actual memory pointing to isn't sanitized.
Just free the params array pointer and then the struct itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Pass the parameter clock rt to qemu to ensure that the
virtual machine is not synchronized with the host time
Signed-off-by: gongwei <gongwei@smartx.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The headers weren't removed after use of VIR_STRDUP was removed.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
"f + 0.5" does not round correctly for values very close to
".5" for every integer multiple, e.g. "0.499999975".
Found by clang-tidy's "bugprone-incorrect-roundings" check.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
`udevGetIntSysfsAttr` does not necessarily write to the third parameter,
even when it returns 0.
This was found by clang-tidy's
"clang-analyzer-core.UndefinedBinaryOperatorResult" check.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This was found by clang-tidy's
"clang-analyzer-security.insecureAPI.bzero" check.
bzero is marked as deprecated ("LEGACY") in POSIX.1-2001 and
removed in POSIX.1-2008.
Besides its deprecation, bzero can be unsafe to use under certain
circumstances, e.g. when used to zero-out memory containing secrects.
These calls can be optimized away by the compiler, if it concludes no
further access happens to the memory, thus leaving the secrets still
in memory. Hence its classification as "insecureAPI".
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This was found by clang-tidy's "readability-misleading-indentation"
check.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This was found by clang-tidy's "readability-misleading-indentation"
check.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This section is guarded by "#ifndef WIN32" in line 2109--2808.
Found by clang-tidy's "readability-redundant-preprocessor" check.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Co-authored-by: Sri Ramanujam <sramanujam@datto.com>
Signed-off-by: Matt Coleman <matt@datto.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This patch takes on one set of examples of unnecessary use of
VIR_FREE() when g_free() is adequate - it modifies only vir*Free()
functions within the conf directory that take a single pointer and
free the object pointed to by that argument before returning. The
modification is to replace VIR_FREE() with g_free() for the object
itself *and* for all subordinate chunks of memory pointed to by that
object.
(NB: there are other functions that VIR_FREE subordinate memory of
objects that end up being freed before return (also sometimes with
VIR_FREE); I am purposefully ignoring those to reduce scope and focus
on a sub class where the pointlessness is obvious.)
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
usually a function call vir*Free() will take a single pointer to an
object as its argument, and will then free all resources associated
with that object, including the object
itself. virStorageEnctyptionInfoDefFree() doesn't do that - it frees
all the subordinate resources of the ojbect, but doesn't free the
object itself; usually a function like that is called
vir*Clear(). Let's rename this function to not be misleading.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There is no point in setting the interface model to unknown during
virDomainNetDefFree(), since we are about to free the object anyway
(and the model isn't used anywhere in the rest of the function).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The memory containing the pointer is going to be freed momentarily anyway.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This function clears out and frees a virDomainZPCIAddressIds object,
so that's that's what it should take as its argument, *not* the
pointer to a parent object that contains the object we want to free.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Back in commit 2c71d3826, which appeared in libvirt-1.2.3 in April
2014, the location used to store saved MAC addresses and vlan tags of
SRIOV VFs was changed from /var/run/libvirt/qemu to
/var/run/libvirt/hostdevmgr. For backward compatibility the code was
made to continue looking in the old location for the files when it
didn't find them in the new location.
It's now been 6 years, and even if there was somebody still running
libvirt-1.2.3 on their system, that system would now be out of support
for libvirt, so there would be no way for them to upgrade to a new
libvirt that no longer looks in "oldStateDir" for the files. So
let's no longer look in "oldStateDir" for the files!
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virGetConnectNetwork() calls
virGetConnectGeneric(), which calls
virConnecCacheInitialize(), which is actually a call (only once) to
virConnectCacheOnceInit() which calls
virThreadLocalInit() several times, which calls
pthread_key_create()
If pthread_key_create() fails, it (of course) doesn't log an error
(because it's not a part of libvirt), nor does any other function on
the call chain all the way up to virGetConnectNetwork(). But none of
the callers of virGetConnectNetwork() log an error either, so it is
possible that an API could fail due to virGetConnectNetwork() failing,
but would only log "an error was encountered, but the cause is
unknown. Deal with it." (paraphrasing).
(In all likelyhood, virConnectCacheOnceInit() is going to be called at
some earlier time, and almost certainly pthread_key_create() will
never fail (and if it does, the user will have *much* bigger problems
than an obtuse error message from libvirt)).
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
posix_fallocate() might be not supported by a filesystem, for example,
it's not supported by ZFS. In that case it fails with
return code 22 (EINVAL), and thus safezero_posix_fallocate() returns -1.
As safezero_posix_fallocate() is the first function tried by safezero()
and it tries other functions only when it returns -2, it fails
immediately without falling back to other methods, such as
safezero_slow().
Fix that by returning -2 if posix_fallocate() returns EINVAL, to give
safezero() a chance to try other functions.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current virPCIDeviceNew() signature, receiving 4 uints in sequence
(domain, bus, slot, function), is not neat.
We already have a way to represent a PCI address in virPCIDeviceAddress
that is used in the code. Aside from the test files, most of
virPCIDeviceNew() callers have access to a virPCIDeviceAddress reference,
but then we need to retrieve the 4 required uints (addr.domain, addr.bus,
addr.slot, addr.function) to satisfy virPCIDeviceNew(). The result is
that we have extra verbosity/boilerplate to retrieve an information that
is already available in virPCIDeviceAddress.
A better way is presented by virNVMEDeviceNew(), where the caller just
supplies a virPCIDeviceAddress pointer and the function handles the
details internally.
This patch changes virPCIDeviceNew() to receive a virPCIDeviceAddress
pointer instead of 4 uints.
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Instead of receiving 4 uints in order and write domain/bus/slot/function,
receive a virPCIDeviceAddressPtr instead and write into it.
This change will allow us to simplify the API for virPCIDeviceNew()
in the next patch.
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
libxlNodeDeviceGetPCIInfo() and qemuNodeDeviceGetPCIInfo() are equal.
Let's move the logic to a new virDomainDriverNodeDeviceGetPCIInfo()
info to be used by libxl_driver.c and qemu_driver.c.
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
There is no need to open code the PCI address string format
when we have a function that does exactly that.
Reviewed-by: Laine Stump <laine@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
