The current lazy network sandbox initialization code has a race
in that if multiple go routines race to join the network the second
and subsequent go routines might try to use the sandbox before it is
fully initialized. Fix this by blocking the go routines in once.Do
calls and also take of care of rolling back properly in case of
error.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- In DeleteEndpoint(), veth removal is a best effort,
as it could have alreayd been removed by sandbox destroy.
Therefore if veth is not found, cleanup defer function
should not run.
Signed-off-by: Alessandro Boch <aboch@docker.com>
- In case of sandboxAdd() failure, drive.Leave() call
in first executed defer reset err to nil. Secondly
executed defer in charge of resetting ep.container to nil
will not get executed.
Signed-off-by: Alessandro Boch <aboch@docker.com>
for the bridge driver.
Moves two config options, namely EnableIPTables and EnableUserlandProxy
from networks to the driver.
Closes#242
Signed-off-by: Mohammad Banikazemi <MBanikazemi@gmail.com>
14.10 reached EOL recently and hence experimental builds are not built for
that distro any more. Upgrading it to 15.04 means handling the systemd
specific docker daemon configs required for multi-host networking.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
As seen in https://github.com/docker/docker/issues/14738 there is
general instability in the later kernels under race conditions when ioctl
calls are used in parallel with netlink calls for various operations.
(We are yet to narrow down to the exact root-cause on the kernel).
For those older kernels which doesnt support some of the netlink APIs,
we can fallback to using ioctl calls. Hence bringing back the original
code that used netlink (https://github.com/docker/libnetwork/pull/349).
Also, there was an existing bug in bridge creation using netlink which
was setting bridge mac during bridge creation. That operation is not
supported in the netlink library (and doesnt throw an error either).
Included a fix for that condition by setting the bridge mac after
creating the bridge.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
The controller sandboxes hashmap is not being protected by a lock
while deleting it in `LeaveAll` call. This may result in a race
whereby any other read access that happens with the lock held is
also vulnerable to return random sandbox data which could result
in totally unpredictable behavior.
Also as part of the fix check if `s.endpoints` is empty and log an
error in `rmEndpoint` so that we don't bring down the process
for this unexpected error.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
TL;DR: check for IsExist(err) after a failed MkdirAll() is both
redundant and wrong -- so two reasons to remove it.
Quoting MkdirAll documentation:
> MkdirAll creates a directory named path, along with any necessary
> parents, and returns nil, or else returns an error. If path
> is already a directory, MkdirAll does nothing and returns nil.
This means two things:
1. If a directory to be created already exists, no error is
returned.
2. If the error returned is IsExist (EEXIST), it means there exists
a non-directory with the same name as MkdirAll need to use for
directory. Example: we want to MkdirAll("a/b"), but file "a"
(or "a/b") already exists, so MkdirAll fails.
The above is a theory, based on quoted documentation and my UNIX
knowledge.
3. In practice, though, current MkdirAll implementation [1] returns
ENOTDIR in most of cases described in #2, with the exception when
there is a race between MkdirAll and someone else creating the
last component of MkdirAll argument as a file. In this very case
MkdirAll() will indeed return EEXIST.
Because of #1, IsExist check after MkdirAll is not needed.
Because of #2 and #3, ignoring IsExist error is just plain wrong,
as directory we require is not created. It's cleaner to report
the error now.
[1] https://github.com/golang/go/blob/f9ed2f75/src/os/path.go
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
- NetworkRange() function on which ipallocatore relies
to compute the subnet limits has a bug in computing the upper limit IP
- in case container subnet is specified (fixedCIDR), bridge driver to
reserve bridge and gateway addresses only if they belong to the container
subnet
- Make ipallocator more robust in using converting the passed network
to a canonical one before using it as a key in its public APIs
Signed-off-by: Alessandro Boch <aboch@docker.com>
Two changes were missing:
- On allocation of bridge ip was not passing canonical subnet
- Canonical subnet has to be passed on ip release
as well, otherwise ipallocator will attempt
ip release from a non registered nw
Signed-off-by: Alessandro Boch <aboch@docker.com>
Set the hairpin mode using the sysfs interface which
looks like it is working all the way to the oldest
of RHEL6.6 kernels.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
When you start a container after some other container has already
been started in the same network, the current container will have
an fdb which points to a wrong vtep to reach the already started
container. This makes the network connectivity to not work. The root
cause of the issue is because of golang does variable capture by
reference in closures and so we cannot use the return values from
range iterators directly. It needs to be copied to a locally scoped
variable and then use that copy as a capture variable in the closure.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
