The function will attempt to read a pid from @path, and store it in
@pid. The @pid will only be set, however, if @path is locked by
virFileLock() at byte 0 and the pid in @path is running.
Signed-off-by: Vasiliy Ulyanov <vulyanov@suse.de>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
SmartNIC DPUs may not expose some privileged eswitch operations
to the hypervisor hosts. For example, this happens with Bluefield
devices running in the ECPF (default) mode for security reasons. While
VF MAC address programming is possible via an RTM_SETLINK operation,
trying to set a VLAN ID in the same operation will fail with EPERM.
The equivalent ip link commands below provide an illustration:
1. This works:
sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe
2. Setting (or clearing) a VLAN fails with EPERM:
sudo ip link set enp130s0f0 vf 2 vlan 0
RTNETLINK answers: Operation not permitted
3. This is what Libvirt attempts to do today (when trying to clear a
VF VLAN at the same time as programming a VF MAC).
sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe
RTNETLINK answers: Operation not permitted
If setting an explicit VLAN ID results in an EPERM, clearing a VLAN
(setting a VLAN ID to 0) can be handled gracefully by ignoring the
EPERM error with the rationale being that if we cannot set this state
in the first place, we cannot clear it either.
In order to keep explicit clearing of VLAN ID working as it used to
be passing a NULL pointer for VLAN ID is used.
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There should be a way to show no intent in programming a VLAN at all
(including clearing it). This allows handling error conditions
differently when VLAN clearing is explicit (vlan id == 0) vs implicit
(vlanid == NULL - try to clear it if possible).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This has a benefit of being able to handle error codes for those
operations separately which is useful when drivers allow setting a MAC
address but do not allow setting a VLAN (which is the case with some
SmartNIC DPUs).
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some files do not include what they use and rely on virutil.h
to pull in the necessary header files.
Fix it.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Identifies all of various MIPS sub-architectures: 32-bit or 64-bit,
little-endian or big-endian.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are few places where the g_steal_pointer() is open coded.
Switch them to calling the g_steal_pointer() function instead.
Generated by the following spatch:
@ rule1 @
expression a, b;
@@
<...
- b = a;
... when != b
- a = NULL;
+ b = g_steal_pointer(&a);
...>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@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>
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 938382b60a.
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 fd00f0e6c7
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>
