commit db488c79 assumed that dnsmasq would complete IPv6 DAD before
daemonizing, but in reality it doesn't wait, which creates problems
when libvirt's bridge driver sets the matching "dummy tap device" to
IFF_DOWN prior to DAD completing.

This patch waits for DAD completion by periodically polling the kernel
using netlink to check whether there are any IPv6 addresses assigned
to bridge which have a 'tentative' state (if there are any in this
state, then DAD hasn't yet finished). After DAD is finished, execution
continues. To avoid an endless hang in case something was wrong with
the kernel's DAD, we wait a maximum of 5 seconds.

The internal representation of a JSON array counts the items in
size_t. However, for some reason, when asking for the count it's
reported as int. Firstly, we need the function to return a signed
type as it's returning -1 on an error. But, not every system has
integer the same size as size_t. Therefore, lets return ssize_t.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's a check right at the beginning of the function that
shortcuts if the function was called over all NULL arguments.
However, this was meant just as a fool-proof check so that we
don't crash if function is used in a bad manner. Anyway, it makes
Coverity unhappy as it then thinks any of the arguments could be
NULL. Well, with the current state of the code it can't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It may happen that an interface don't have any bandwidth set and
a new one is to be set. In that case, @ifaceBand will be NULL.
This will cause troubles later in the code when deciding what to
do.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So, if a domain vNIC's bandwidth has been successfully set, it's
possible that because @floor is set on network's bridge, this
part may need updating too. And that's exactly what this function
does. While the previous commit introduced a function to check if
@floor can be satisfied, this does all the hard work. In general,
there may be three, well four possibilities:

  1) No change in @floor value (either it remain unset, or its
  value hasn't changed)

  2) The @floor value has changed from a non-zero to a non-zero
  value

  3) New @floor is to be set

  4) Old @floor must be cleared out

The difference between 2), 3) and 4) is, that while in 2) the QoS
tree on the network's bridge already has a special class for the
vNIC, in 3) the class must be created from scratch. In 4) it must
be removed. Fortunately, we have helpers for all three
interesting cases.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When a domain vNIC's bandwidth is to be changed (at runtime) it is
possible that guaranteed minimal bandwidth (@floor) will change too.
Well, so far it is, because we still don't have an implementation that
allows setting it dynamically, so it's effectively erased on:

    #virsh domiftune $dom vnet0 --inbound 0

However, that's slightly unfortunate. We do some checks on domain
startup to see if @floor can be guaranteed. We ought do the same if
QoS is changed at runtime.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is no functional change. It's just that later in the series we
will need to pass class_id as an integer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There are now many more reasons that virSocketAddrGetRange() could
fail, so it is much more informative to report the error there instead
of in the caller. (one of the two callers was previously assuming
success, which is almost surely safe based on the parsing that has
already happened to the config by that time, but it still is nicer to
account for an error "just in case")

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

This loop had automatic variable definitions mixed with code. This
patch moves the definitions to the top of the function and puts
cleanup for them at the bottom. No functional change.

Part of fix for: https://bugzilla.redhat.com/show_bug.cgi?id=985653

virSocketAddrGetRange() has been updated to take the network address
and prefix, and now checks that both the start and end of the range
are within that network, thus validating that the entire range of
addresses is in the network. For IPv4, it also checks that ranges to
not start with the "network address" of the subnet, nor end with the
broadcast address of the subnet (this check doesn't apply to IPv6,
since IPv6 doesn't have a broadcast or network address)

Negative tests have been added to the network update and socket tests
to verify that bad ranges properly generate an error.

This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=985653

To silence Coverity just add a 'p &&' in front of the check in
networkFindUnusedBridgeName after the strchr() call.  Even though
we know it's not possible to have strchr return NULL since the only
way into the function is if there is a '%' in def->bridge or it's NULL.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

For some reason, we allow a bridge name with %d in it, which we replace
with an unsigned integer to form a bridge name that does not yet exist
on the host.

Do not blindly pass it to virAsprintf if it's not the only conversion,
to prevent crashing on input like:

<network>
  <name>test</name>
  <forward mode='none'/>
  <bridge name='virbr%d%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s'/>
</network>

Ignore any template strings that do not have exactly one %d conversion,
like we do in various drivers before calling virNetDevTapCreateInBridgePort.

Since some people use the same naming convention as libvirt for bridge
devices they create outside the context of libvirt, it is much nicer
if we check for those devices when looking for a bridge device name to
auto-assign to a new network.

We already check that any auto-assigned bridge device name for a
virtual network (e.g. "virbr1") doesn't conflict with the bridge name
for any existing libvirt network (via virNetworkSetBridgeName() in
conf/network_conf.c).

We also want to check that the name doesn't conflict with any bridge
device created on the host system outside the control of libvirt
(history: possibly due to the ploriferation of references to libvirt's
bridge devices in HOWTO documents all around the web, it is not
uncommon for an admin to manually create a bridge in their host's
system network config and name it "virbrX"). To add such a check to
virNetworkBridgeInUse() (which is called by virNetworkSetBridgeName())
we would have to call virNetDevExists() (from util/virnetdev.c); this
function calls ioctl(SIOCGIFFLAGS), which everyone on the mailing list
agreed should not be done from an XML parsing function in the conf
directory.

To remedy that problem, this patch removes virNetworkSetBridgeName()
from conf/network_conf.c and puts an identically functioning
networkBridgeNameValidate() in network/bridge_driver.c (because it's
reasonable for the bridge driver to call virNetDevExists(), although
we don't do that yet because I wanted this patch to have as close to 0
effect on function as possible).

There are a couple of inevitable changes though:

1) We no longer check the bridge name during
   virNetworkLoadConfig(). Close examination of the code shows that
   this wasn't necessary anyway - the only *correct* way to get XML
   into the config files is via networkDefine(), and networkDefine()
   will always call networkValidate(), which previously called
   virNetworkSetBridgeName() (and now calls
   networkBridgeNameValidate()). This means that the only way the
   bridge name can be unset during virNetworkLoadConfig() is if
   someone edited the config file on disk by hand (which we explicitly
   prohibit).

2) Just on the off chance that somebody *has* edited the file by hand,
   rather than crashing when they try to start their malformed
   network, a check for non-NULL bridge name has been added to
   networkStartNetworkVirtual().

   (For those wondering why I don't instead call
   networkValidateBridgeName() there to set a bridge name if one
   wasn't present - the problem is that during
   networkStartNetworkVirtual(), the lock for the network being
   started has already been acquired, but the lock for the network
   list itself *has not* (because we aren't adding/removing a
   network). But virNetworkBridgeInuse() iterates through *all*
   networks (including this one) and locks each network as it is
   checked for a duplicate entry; it is necessary to lock each network
   even before checking if it is the designated "skip" network because
   otherwise some other thread might acquire the list lock and delete
   the very entry we're examining. In the end, permitting a setting of
   the bridge name during network start would require that we lock the
   entire network list during any networkStartNetwork(), which
   eliminates a *lot* of parallelism that we've worked so hard to
   achieve (it can make a huge difference during libvirtd startup). So
   rather than try to adjust for someone playing against the rules, I
   choose to instead give them the error they deserve.)

3) virNetworkAllocateBridge() (now removed) would leak any "template"
   string set as the bridge name. Its replacement
   networkFindUnusedBridgeName() doesn't leak the template string - it
   is properly freed.

We've been explicitly requesting IPv4 for some reason,
even if there were only IPv6 addresses in the network
definition.

https://bugzilla.redhat.com/show_bug.cgi?id=1192318

Rename it to virNetDevGetIPv4AddressIoctl and make
virNetDevGetIPAddress a wrapper around it, allowing
other ways of getting the address to be implemented,
and still falling back to the old method.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

This function does not make any sense now, that network driver is
(almost) dropped. I mean, previously, when threads were
serialized, this function was there to check, if no other network
with the same name or UUID exists. However, nowadays that threads
can run more in parallel, this function is useless, in fact it
gives misleading return values. Consider the following scenario.
Two threads, both trying to define networks with same name but
different UUID (e.g. because it was generated during XML parsing
phase, whatever). Lets assume that both threads are about to call
networkValidate() which immediately calls
virNetworkObjIsDuplicate().

T1: calls virNetworkObjIsDuplicate() and since no network with
given name or UUID exist, success is returned.
T2: calls virNetworkObjIsDuplicate() and since no network with
given name or UUID exist, success is returned.

T1: calls virNetworkAssignDef() and successfully places its
network into the virNetworkObjList.
T2: calls virNetworkAssignDef() and since network with the same
name exists, the network definition is replaced.

Okay, this is mainly because virNetworkAssignDef() does not check
whether name and UUID matches. Well, lets make it so! And drop
useless function too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to lock the network driver, as network driver
initialization is done prior accepting any client. There's nobody
to hop in and do something over partially initialized driver. Nor
qemu driver is doing that.

==30532== Observed (incorrect) order is: acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x5396440: virNetworkObjListForEach (network_conf.c:4511)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B27B60: networkGetDnsmasqCaps (bridge_driver.c:113)
==30532==    by 0x19B2856A: networkUpdateState (bridge_driver.c:389)
==30532==    by 0x53963E9: virNetworkObjListForEachHelper (network_conf.c:4488)
==30532==    by 0x52E2224: virHashForEach (virhash.c:521)
==30532==    by 0x539645B: virNetworkObjListForEach (network_conf.c:4512)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==
==30532== Required order was established by acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B28DF9: networkStateInitialize (bridge_driver.c:609)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x538A09C: virNetworkAssignDef (network_conf.c:527)
==30532==    by 0x5391EB2: virNetworkLoadState (network_conf.c:3008)
==30532==    by 0x53922D4: virNetworkLoadAllState (network_conf.c:3128)
==30532==    by 0x19B2929A: networkStateInitialize (bridge_driver.c:671)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The following is a long winded way to say this patch is avoiding a
false positive.

Coverity complains that calling networkPlugBandwidth() could eventually
end up with a NULL dereference on iface->bandwidth because in the
networkAllocateActualDevice there's a check of 'iface->bandwidth'
before deciding to try to use the 'portgroup' if it exists or to not
perferm the virNetDevBandwidthCopy if 'bandwidth' is not NULL.

Later in networkPlugBandwidth the 'iface->bandwidth' is sourced from
virDomainNetGetActualBandwidth - which would be either iface->bandwidth
or (preferably) iface->data.network.actual->bandwidth which would have
been filled in from either 'iface->bandwidth' or 'portgroup->bandwidth'
back in networkAllocateActualDevice

There *is* a check in networkCheckBandwidth for the result of the
virDomainNetGetActualBandwidth being NULL and a return 1 based on
that which would cause networkPlugBandwidth to exit properly and thus
never hit the condition that Coverity complains about.

However, since Coverity checks all paths - it somehow believes that
a return of 0 by networkCheckBandwidth in this condition would end
up causing the possible NULL dereference. The "fix" to silence Coverity
is to not have networkCheckBandwidth also call virDomainNetGetActualBandwidth
in order to get the ifaceBand, but rather have it accept it as an argument
which causes Coverity to "see" that it's the exit condition of 1 that won't
have the possible NULL dereference.  Since we're passing that, I added the
passing of iface->mac rather than passing iface as well. This just hopefully
makes sure someone doesn't undo this in the future...

Valgrind detected a leak:

==17820== 102 (56 direct, 46 indirect) bytes in 1 blocks are definitely lost in loss record 479 of 646
==17820==    at 0x4A08946: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17820==    by 0x508521A: virAllocVar (viralloc.c:560)
==17820==    by 0x50D9FCA: virObjectNew (virobject.c:193)
==17820==    by 0x50A4FD9: dnsmasqCapsNewEmpty (virdnsmasq.c:784)
==17820==    by 0x50A514E: dnsmasqCapsNewFromBinary (virdnsmasq.c:830)
==17820==    by 0x1B508287: networkStateInitialize (bridge_driver.c:666)

It looks like commit 172acef4 introduced the problem, because
networkGetDnsmasqCaps() increments the reference count but an
early exit never does a matching decrement.

* src/network/bridge_driver.c (networkStateCleanup): Plug leak.
Signed-off-by: NEric Blake <eblake@redhat.com>

Now that the network driver lock is ash heap of history,
we can use more of networkObjFromNetwork().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Now that we have fine grained locks, there's no need to
lock the whole driver. We can rely on self-locking APIs.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is not an immutable pointer and can change during lifetime.
Therefore, in order to drop network driver lock, we must use an
internal accessor which does not lock the network driver yet, but
it will soon. Now it merely returns an referenced object.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Well, network driver code has the driver accessible as a global
variable. This makes any rework hard, as it's unclear where the
variable is accessed and/or modified. Lets just pass the driver
as a parameter to all functions where needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch turns both virNetworkObjFindByUUID() and
virNetworkObjFindByName() to return an referenced object so that
even if caller unlocks it, it's for sure that object won't
disappear meanwhile. Especially if the object (in general) is
locked and unlocked during the caller run.
Moreover, this commit is nicely small, since the object unrefing
can be done in virNetworkObjEndAPI().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far, this is pure code replacement. But once we introduce
reference counting to virNetworkObj this will be more handy as
there'll be only one function to change: virNetworkObjEndAPI().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far it's just a structure which happens to have 'Obj' in its
name, but otherwise it not related to virObject at all. No
reference counting, not virObjectLock(), nothing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Undefining a running, autostarted domain removes the autostart link, but
dom->autostart is not cleared. If the domain is subsequently redefined,
libvirt thinks it is already autostarted and will not create the link
even if requested:

  # virsh dominfo example | grep Autostart
  Autostart:      enable

  # ls /etc/libvirt/qemu/autostart/example.xml
  /etc/libvirt/qemu/autostart/example.xml

  # virsh undefine example
  Domain example has been undefined

  # virsh define example.xml
  Domain example defined from example.xml

  # virsh dominfo example | grep Autostart
  Autostart:      enable

  # virsh autostart example
  Domain example marked as autostarted

  # ls /etc/libvirt/qemu/autostart/example.xml
  ls: cannot access /etc/libvirt/qemu/autostart/example.xml: No such file or directory

This commit ensures dom->autostart is cleared whenever the config and
autostart link (if present) are removed.

The bridge network driver cleared this flag itself in networkUndefine.
This commit moves this into virNetworkDeleteConfig for symmetry with
virDomainDeleteConfig, and to ensure it is not missed in future network
drivers.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

Instead of finding the next clear bit by calling virBitmapGetBit
in a loop, use the virBitmapNextClearBit helper.

Well, one day this will be self-locking object, but not today.
But lets prepare the code for that! Moreover,
virNetworkObjListFree() is no longer needed, so turn it into
virNetworkObjListDispose().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It's returning virNetworkObjPtr after all. And it matches the
pattern laid out by domain_conf.h.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It's returning virNetworkObjPtr after all. And it matches the
pattern laid out by domain_conf.h.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In order to hide the object internals (and use just accessors
everywhere), lets store a pointer to the object, instead of object
itself.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of copying the whole object onto stack when calling the
function, just pass the pointer to the object and save up some
space on the stack. Moreover, this prepares the code to hide the
virNetworkObjList structure into network_conf.c and use accessors
only.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Moreover, there are two points within the function, where we're
missing 'goto cleanup'. Fix this too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Okay, this is mainly for educational purposes since is called
from single point only with all the possible locks held. So
there's no way for other thread to hop in and do something wrong.
Nevertheless, we should not give bad example.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have this function networkObjFromNetwork() which for given
virNetworkPtr tries to find corresponding virNetworkObjPtr. If no
object is found, a nice error message is printed out:

  no network with matching uuid '$uuid' ($name)

Let's improve the error message produced by networkLookupByUUID to
follow that logic.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

libvirt was unconditionally calling virNetDevBandwidthClear() for
every interface (and network bridge) of a type that supported
bandwidth, whether it actually had anything set or not. This doesn't
hurt anything (unless ifname == NULL!), but is wasteful.

This patch makes sure that all calls to virNetDevBandwidthClear() are
qualified by checking that the interface really had some bandwidth
setup done, and checks for a null ifname inside
virNetDevBandwidthClear(), silently returning success if it is null
(as well as removing the ATTRIBUTE_NONNULL from that function's
prototype, since we can't guarantee that it is never null,
e.g. sometimes a type='ethernet' interface has no ifname as it is
provided on the fly by qemu).