Modeled after "WITH_QEMU_LOCK_GUARD" (see qemu's include/qemu/lockable.h).
See comment for typical usage.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Typical usage:
void foobar(virObjectLockable *obj)
{
VIR_LOCK_GUARD lock = virObjectLockGuard(obj);
/* `obj` is locked, and released automatically on scope exit */
...
}
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Modeled after "WITH_QEMU_LOCK_GUARD" (see qemu's include/qemu/lockable.h).
See comment for typical usage.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Locks a virMutex on creation and unlocks it in its destructor.
The VIR_LOCK_GUARD macro is used instead of "g_auto(virLockGuard)" to
work around a clang issue (see https://bugs.llvm.org/show_bug.cgi?id=3888
and https://bugs.llvm.org/show_bug.cgi?id=43482).
Typical usage:
void function(virMutex *m)
{
VIR_LOCK_GUARD lock = virLockGuardLock(m);
/* `m` is locked, and released automatically on scope exit */
...
while (expression) {
VIR_LOCK_GUARD lock2 = virLockGuardLock(...);
/* similar */
}
}
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Remove pointless 'ret', cmd variable reuse and use g_auto.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use g_auto, split the double use of 'cmd' variable and remove useless
ret variable.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Separate the two uses of 'cmd' to avoid mixing manual and automatic
cleanup.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reduce the scope of the variable to avoid renaming it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Use automatic cleanup and remove the 'ret' variable in favor of
direct returns.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In case virXMLPropUInt() or virXMLPropULongLong() meets an
attribute with a negative integer the following error message is
printed:
Invalid value ...: Expected integer value
This message is not as good as it could be. Let users know it's a
non-negative integer we are expecting.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This reverts commit 938382b60ae5bd1f83b5cb09e1ce68b9a88f679a.
Turns out, the commit did more harm than good. It changed
semantics on some public APIs. For instance, while
qemuDomainGetInfo() previously did not returned an error it does
now. While the calls to virProcessGetStatInfo() is guarded with
virDomainObjIsActive() it doesn't necessarily mean that QEMU's
PID is still alive. QEMU might be gone but we just haven't
realized it (e.g. because the eof handler thread is waiting for a
job).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2041610
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We're currently passing '0' which leaves the syslog facility
unset. Since we're passing an explicit facility for syslog
when using journald, it makes sense to be explicit when
using syslog directly too.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We set SYSLOG_PRIORITY when sending to journald to avoid our
messages getting tagged with the default facility which is
used for the kernel.
Unfortunately:
commit fd00f0e6c75b00c3d97be8670afcd9094b823855
Author: Guido Günther <agx@sigxcpu.org>
Date: Mon Sep 21 20:06:55 2015 +0200
Use daemon log facility for journald
used the LOG_nnn constants from the syslog header without realizing
that these values have a bit-shift applied. While Linux defines a
LOG_FAC() macros to undo the bit-shift this doesn't appear to be
standardized. So the safe thing is to just use the raw value since
these values are fixed by RFC 5424.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It was only used to construct the hash key for the (now removed)
shared devices in the qemu driver.
Remove it and its mocking.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
unpriv_sgio was a downstream-only feature in RHEL 6-8.
The libvirt support was merged upstream by mistake.
Remove the function that constructs the sysfs path and assume it
does not exist in all the callers.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The virNetDevOpenvswitchInterfaceSetQos function is uneven
because setting the Rx Qos is open-coded, while clearing it
is sepearated in another function.
Separate the setting too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The virNetDevOpenvswitchInterfaceSetQos function is uneven
because setting the Tx Qos is open-coded, while clearing it
is sepearated in another function.
Separate the setting too.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These functions are called by virNetDevOpenvswitchInterfaceSetQos
as well as virNetDevOpenvswitchInterfaceClearQos.
Move them above both fuctions.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We don't do anything with it after checking that it satisfies our
requirements and don't provide a way for users of the module to
access it, so carrying it around is pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
After previous cleanups, there's just one caller of
dnsmasqCapsNewEmpty() and it is dnsmasqCapsNewFromBinary().
And the former is pretty short. Therefore, it is not necessary
for the code to live in two separate functions. Dissolve the
former in the latter.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
First observation: There is no way that caps->binaryPath can be
NULL. Second observation: There is no caller that passes NULL.
Let's drop the ternary operator and access @caps directly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
While it's true that our virCommand subsystem is happy with
non-absolute paths, the dnsmasq capability code is not. It stores
the path to dnsmasq within and makes it accessible via
dnsmasqCapsGetBinaryPath(). While strictly speaking no caller
necessarily needs canonicalized path, let's find dnsmasq once and
cache the result.
Therefore, when constructing the capabilities structure look up
the binary path. If DNSMASQ already contains an absolute path
then virFindFileInPath() will simply return a copy.
With this code in place, the virFileIsExecutable() check can be
removed from dnsmasqCapsRefreshInternal() because
virFindFileInPath() already made sure the binary is executable.
But introducing virFindFileInPath() means we have to mock it in
test suite because dnsmasqCaps are created in
networkxml2conftest.
Moreover, we don't need to check for dnsmasq in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We don't query any capabilities of dnsmasq. We are only
interested in dnsmasq's version (obtained via 'dnsmasq
--version'). Therefore, there's no point in running 'dnsmasq
--help'. Its output is not processed even.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There is no way that the dnsmasqCapsRefreshInternal() function
can be called with @caps == NULL. Therefore, drop the if() that
checks for that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The noRefresh member of _dnsmasqCaps struct is set only after it
was checked for and is never checked again. This is needless and
the member can be removed. There is no way that
dnsmasqCapsRefreshInternal() can be called after
dnsmasqCapsSetFromBuffer().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The _dnsmasqCaps struct has @mtime member which holds the mtime
of the dnsmasq binary. The idea was that capabilities don't need
to be queried if mtime hasn't changed since the last time.
However, the code that would try to query capabilities again was
removed and now we are left with code that stores mtime but has
no use for it.
Remove the member and code that uses it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This argument is not used really as the only caller passes true
and dnsmasqCapsRefreshInternal() only checks for false value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The dnsmasqCaps type has its own cleanup function defined and
ready to use via g_autoptr(). Use automatic cleanup instead of
an explicit one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Both callers of dnsmasqCapsNewEmpty() pass DNSMASQ as an argument
which is then fed to a ternary operator which looks like this
(after substitution).
DNSMASQ ? DNSMASQ : DNSMASQ
While I like tautologies, the code can be simplified by dropping
the argument.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The way that virConfSetValue() works (and the way it is even
documented) is that the @value pointer is always consumed.
However, since the first order pointer is passed it leaves
callers in a pickle situation - they always have to set pointer
to NULL after calling virConfSetValue() to avoid touching it.
Let's switch @value to a double pointer and clear it inside the
function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This commit declares g_autoptr() function for virConfValue type.
At the same time, it switches variable declarations to use it.
Also, in a few places we might have freed a variable twice, for
instance in xenFormatXLDomainNamespaceData(). This is because
virConfSetValue() consumes passed pointer (@value) even in case
of failure and thus any code that uses virConfSetValue() must
refrain from touching @value and it must not call
virConfFreeValue().
This semantic is not obvious and will be addressed in one of
future commits.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Callers of virConfSetValue() don't report any error, they just
pass the error blindly. Therefore, report an error when
virConfSetValue() is about to fail.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently virProcessGetStatInfo() always returns success and only logs error
when it is unable to parse the data. Make this function actually report the
error and return a negative value in this error scenario.
Fix the callers so that they do not override the error generated.
Also fix non-linux implementation of this function so as to report error.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are a few glib functions that abort on OOM and thus there's
no point in checking their retval against NULL. Nevertheless, we
do have those checks in a few places. Remove them.
Generated using the following spatch:
@@
expression x;
identifier n;
expression r;
@@
(
x = g_strdup_printf(...);
| x = g_strdup_vprintf(...);
| x = g_strdup(...);
| x = g_strndup(...);
| x = g_new0(...);
| x = g_realloc(...);
)
... when != x
- if(!x)
(
- return r;
|
- goto n;
)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Both virProcessGetStatInfo() and virProcessGetSchedInfo() are
Linux centric. Provide stubs for non-Linux platforms.
Fixes: d73852c49962fbfe652fc7bec595a3f242faf847
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virURIParamAppend() unconditionally returns 0. Simplify and make the return type
as void type.
Signed-off-by: Ani Sinha <ani@anisinha.ca>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Move qemuGetProcessInfo and qemuGetSchedInfo methods to util and share them
with ch driver.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The commit that added error checking to this function
forgot to adjust the WIN32 stub.
Fixes: a873924e36b28c5b125621e35b32beb6b077bcc8
Signed-off-by: Ján Tomko <jtomko@redhat.com>
And make callers check the return value as well. This helps error out early for
invalid environment variables.
That is desirable because it could lead to deadlocks. This can happen when
resetting logging after fork() reports translated errors because gettext
functions are not reentrant. Well, it is not limited to resetting logging after
fork(), it can be any translation at that phase, but parsing environment
variables is easy to make fail on purpose to show the result, it can also happen
just due to a typo.
Before this commit it is possible to deadlock the daemon on startup
with something like:
LIBVIRT_LOG_FILTERS='1:*' LIBVIRT_LOG_OUTPUTS=1:stdout libvirtd
where filters are used to enable more logging and hence make the race less rare
and outputs are set to invalid
Combined with the previous patches this changes
the following from:
...
<deadlock>
to:
...
libvirtd: initialisation failed
The error message is improved in future commits and is also possible thanks to
this patch.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This prevents starting any daemons with improper logging settings. This is
desirable on its own, but will be even more beneficial when more functions start
reporting errors and failing on them, coming up in following patches
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The only difference is that we are not going to be guaranteed that the mutex is
normal (as opposed to recursive, although there is no system known to me that
would default to recursive mutexes), but that was done only to find occasional
errors (during runtime, back in 2010, commit 336fd879c00b). Functions using
this mutex are mostly stable and unchanging, and it makes the virLogOnceInit()
function only return 0 (or possibly abort in glib calls). On top of that we can
assume that the virLogMutex is always initialized which enables us to be more
consistent in some early error reporting.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
