Fixes#5166
Current graph.restore is essentially O(n^2 log n) due to how
suffixarray creation works.
Rather than create/append/create new this supports creation from a seed
array of ids.
Functional testing shows this eliminates the hang on Creating image
graph reported on list.
Docker-DCO-1.1-Signed-off-by: Paul Nasrat <pnasrat@gmail.com> (github: pnasrat)
Upstream-commit: 4f169c2db512d2ea9ed5729df375896a1ee90347
Component: engine
If the bridge specified using -b/--bridge doesn't
exist, fail instead of attempting to create it.
This is consistent with the docker documentation
on -b/--bridge: "Attach containers to a pre
existing network bridge".
It is also less surprising in an environment where
the operator expected the bridge to be properly
set up before docker starts and expects docker to
fail fast if the bridge was not up instead of
masking this error and coming up in some
potentially broken state.
With this patch, docker still creates docker0 if
needed and no bridge was explicitly specified.
Docker-DCO-1.1-Signed-off-by: Daniel Norberg <daniel.norberg@gmail.com> (github: danielnorberg)
Upstream-commit: 336199a877014143bac462e98cae7f59525a0556
Component: engine
This also migrates the volumes from integration tests into the new cli
integration test framework.
Docker-DCO-1.1-Signed-off-by: Michael Crosby <michael@crosbymichael.com> (github: crosbymichael)
Upstream-commit: af9746412b6070063f105ae97eba1f8fbd56bd22
Component: engine
`filepath.Abs` does more than just `filepath.IsAbs` - namely, `filepath.Clean`, which resolves things like `.../.` or `.../../...`, and causes even an absolute path like `/some/path/../absolute` to fail (or, in my case, `/path/to/docker/.`)
Just using `filepath.IsAbs` directly is a much cheaper check, too. :)
Docker-DCO-1.1-Signed-off-by: Andrew Page <admwiggin@gmail.com> (github: tianon)
Upstream-commit: 603088be928564be2d863a897fbc1729adc74814
Component: engine
The local resolver warning needed to be moved at daemon start because it
was only show for the first container started anyways before having a
default value set.
Docker-DCO-1.1-Signed-off-by: Michael Crosby <michael@crosbymichael.com> (github: crosbymichael)
Upstream-commit: 919dbbe44df0722ca35538223a9c89e71856ec88
Component: engine
This also includes some portability changes so that the package can be
imported with the top level runtime.
Docker-DCO-1.1-Signed-off-by: Michael Crosby <michael@crosbymichael.com> (github: crosbymichael)
Upstream-commit: 82f37b874ea17c5e0040f3e41dc761c88d576e33
Component: engine
This also improves the logic around formatting the labels for selinux
Docker-DCO-1.1-Signed-off-by: Michael Crosby <michael@crosbymichael.com> (github: crosbymichael)
Upstream-commit: 94233a204f82f857536c16f36f94d3a8ff0069dd
Component: engine
There is a bug in the SELinux patch for the lxc execdriver, that
causes lxc containers to blow up whether or not SELinux is enabled.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Upstream-commit: ca4224762b5fe9a319b6c1724ee16d1552403269
Component: engine
Such nodes could already be created by importing a tarball to a container; now
they can be created from within the container itself.
This gives non-privileged containers the mknod kernel capability, and modifies
their cgroup settings to allow creation of *any* node, not just whitelisted
ones. Use of such nodes is still controlled by the existing cgroup whitelist.
Docker-DCO-1.1-Signed-off-by: Kevin Wallace <kevin@pentabarf.net> (github: kevinwallace)
Upstream-commit: c94111b61988ad32d87f99d4421cbcde018c3fb4
Component: engine
As explained in https://github.com/dotcloud/docker/issues/4979
--volumes-from fails with ENOFILE errors.
This is because the code tries to look at the "from" volume without
ensuring that it is mounted yet. We fix this by mounting the containers
before stating in it.
Also includes a regression test.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: bd94f84ded944ab69c18cf9d23c35deee3b15963
Component: engine
We currently drop the global lock while holding a per-device lock when
waiting for device removal, and then we re-aquire it when the sleep is done.
This is causing a AB-BA deadlock if anyone at the same time tries to do any
operation on that device like this:
thread A: thread B
grabs global lock
grabs device lock
releases global lock
sleeps
grabs global lock
blocks on device lock
wakes up
blocks on global lock
To trigger this you can for instance do:
ID=`docker run -d fedora sleep 5`
cd /var/lib/docker/devicemapper/mnt/$ID
docker wait $ID
docker rm $ID &
docker rm $ID
The unmount will fail due to the mount being busy thus causing the
timeout and the second rm will then trigger the deadlock.
We fix this by adding a lock ordering such that the device locks
are always grabbed before the global lock. This is safe since the
device lookups now have a separate lock.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 2ffef1b7eb618162673c6ffabccb9ca57c7dfce3
Component: engine
Currently access to the Devices map is serialized by the main
DeviceSet lock, but we need to access it outside that lock, so we
add a separate lock for this and grab that everywhere we modify
or read the map.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 70826e8b3fee27b971852aad89053507c6866d3e
Component: engine
This centralizes the lookup of devices so it is only done in one place.
This will be needed later when we change the locking for it.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: e01b71cebeb96755641a18762dea5b843f107bee
Component: engine
We already have this at the caller, no need to look up again.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 74edcaf1e84aa8bf35e496b2bead833172a79fca
Component: engine
We already have the info in most cases, no need to look this up multiple times.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 5955846774c9b43291d6de0584fa8c3f62414c43
Component: engine
All the callers already have the info, no need for an extra lookup.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 8e39b35c7cd02bbb644b7faf2a434de0098e6dea
Component: engine
There is no need to look this up again, we have it already in all callers.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: e5394e35c7a8f730ac76d24dee74d769049a0428
Component: engine
Fixes#4741
Right now volumes from expected a dir and not a file so when the drivers
tried to do the bind mount, the destination was a dir, not a file so it
fails to run.
Docker-DCO-1.1-Signed-off-by: Michael Crosby <michael@crosbymichael.com> (github: crosbymichael)
Upstream-commit: a57900e35f2c30026a070fdfdbdb0ce99b35e1ff
Component: engine
The change in commit a9fa1a13c3b0a654a96be01ff7ec19e8009b2094
made us only deactivate devices that were mounted. Unfortunately
this made us not deactivate the base device. Which caused
us to not be able to deactivate the pool.
This fixes that by always just deactivating the base device.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 66c5e19f9bd057644fab475499ea45bb428ba2b2
Component: engine
If an admin mounts all file systems as -rshared (Default on RHEL and Fedora)
we see a scaling problem as the number of container increase.
Basically every new container needs to have it new mounts in /var/lib/docker
shared to all other containers, this ends up with us only able to scale to
around 100 containers, before the system slows down.
By simply bind mounting /var/lib/docker on its and then setting it private,
the scaling issue goes away.
Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
Upstream-commit: 792bb41e524615486ef8266b7bf4804b4fe178f1
Component: engine
