The remoteOpenConn() function was refactored recently. As a part
of that new variable @newconn was introduced which holds
virConnect object as it's being gradually constructed throughout
the function. At the very end, when everything succeeded the
variable is stolen into passed @conn. However, there was one
line missed in the refactor which still access the @conn instead
of @newconn leading to a NULL dereference.
Fixes: f7c422993e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Use a temporary variable 'newconn' to hold the newly opened connection
until we are ready to pass it back instead of the original connection.
This way we can avoid complicated 'error'/'cleanup' sections.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Refactor the code to use virTypedParamList which simplifies cleanup.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The 'identparams' typed parameter list obtained from
virIdentityGetParameters is leaked when called from
'virGetConnectGeneric'.
Use 'virTypedParamListFromParams' to absorb it into a virTypedParamList
which can be autofreed.
Note that the memleak is observable only when running in split-daemon
mode.
Closes: https://gitlab.com/libvirt/libvirt/-/issues/314
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The helper constructs a virTypedParamList from loose params.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Currently translated at 22.9% (2386 of 10419 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
Remove the argument from the function prototypes and the callback
handler.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Access the 'driver' struct from the private data rather than the passed
opaque pointer in preparation to remove the opaque pointer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to the qemu driver if we store the immutable driver pointer in
the VM private data struct we don't have to questionably pass it through
opaque pointers to callbacks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The returned value is used to unlock the object, so all callers must
necessarily make use of the returned value.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When dealing with fdsets only we don't need to pass the FD first as we
now generate fdset name directly. Also there are no more caveats in
passing multiple FDs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the 'direct' mode was separated and thus we don't have any
possible error case we can stop returning any values and simplify
callers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This finishes the separation of the fdset and direct helpers. Remove
'qemuFDPassNewDirect' and all internals which were applicable only in
direct mode.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The callers adding the FDs are validating them regardless so this check
was redundant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unix socket chardevs with FD passing need to use the direct mode so we
need to convert it to use qemuFDPassDirect.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally I envisioned a common set of APIs for both FD passing
approaches but it turns out they are not really compatible enough for it
to make sense to use one set of APIs.
As of such introduce a distinct set of APIs for the 'direct' mode, which
will later be used to convert all places that currently use
'qemuFDPassNewDirect' and later clean up the existing APIs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the internal documentation about qemu threading to the knowledge
base.
The conversion included rstizing of the text document, mainly just
fixing of the headline and enclosing function names and code examples
into code block sections.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
