Note, on x86_64 for 4.12.9 a new kernel option,
HARDLOCKUP_CHECK_TIMESTAMP was added which defaults to enabled. It enables
a low pass filter to compensate for perf based hard lockup detection.
Added this option to the x86_64 4.12.x kernel confog file.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Due to https://github.com/moby/moby/issues/34199 we can't supply
the FROM image via --build-arg and use DOCKER_CONTENT_TRUST=1 for build.
So we pull the image with DCT and then explicitly build it without.
This regression was introduced with 8b84baf2 ("kernel: Allow disabling content trust")
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Tested with:
- boot from kernel + initrd with metadata (appears as sr0)
- boot from iso with no metadata (root is sr0)
- boot from iso with metadata (root is sr0, metadata is sr1)
- boot from iso with metadata using containerized qemu
In all cases where it was present the metadata was correctly expanded to
/var/config.
Signed-off-by: Ian Campbell <ijc@docker.com>
For some use cases, we may want to add additional kernel
configuration options (e.g. when adding AUFS). This commit
enables it by:
- renaming DEBUG to EXTRA
- append kernel_config${EXTRA} to the kernel config
- allowing passing in an EXTRA argument to the make file
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
specifying NOTRUST=1 on the make command line disables
content trust just like with packages.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Without this change, recent Docker build produce this warning:
[WARNING]: Empty continuation line found in:
RUN apk add xz xz-dev zlib-dev && if [ $(uname -m) == x86_64 ]; then apk add libunwind-dev;
fi
[WARNING]: Empty continuation lines will become errors in a future release.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This removes all the code that had knowledge of how to do read only
and read write container mounts, and just uses the runtime config.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This could be used in LinuxKit now, as there are some examples, eg
https://github.com/linuxkit/linuxkit/blob/master/blueprints/docker-for-mac/base.yml#L33
which are creating containers to do a mount.
The main reason though is to in future change the ad hoc code that generates
overlay mounts for writeable containers with a runtime config which does
the same thing; this code needs to create both tmpfs and overlay mounts.
See https://github.com/moby/tool/pull/145
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- The x86_64 kernel config was derived from our 4.11 config
and then adjusted with the recent changes
- The arm64 kernel config was derived from the 4.9 config
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The VMBus/Hyper-V socket patches were partly taken from the now
defunct 4.11 tree and partly form the WIP 4.12 tree at:
https://github.com/dcui/linux/commits/decui/msft-4.12.y
From the 4.11 tree:
- 0001-tools-build-Add-test-for-sched_getcpu.patch
Does not apply, may not be needed anymore to compile perf
- 0002-vmbus-vmbus_open-reset-onchannel_callback-on-error.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0003-vmbus-add-the-matching-tasklet_enable-in-vmbus_close.patch
Already upstream: 5116f5e2e05cf("vmbus: re-enable channel tasklet")
- 0004-vmbus-remove-goto-error_clean_msglist-in-vmbus_open
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0005-vmbus-dynamically-enqueue-dequeue-a-channel-on-vmbus.patch
From the 4.11 patches
- 0006-hv_sock-implements-Hyper-V-transport-for-Virtual-Soc.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0007-VMCI-only-try-to-load-on-VMware-hypervisor.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0008-hv_sock-add-the-support-of-auto-loading.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0009-tools-hv_sock-2-simple-test-cases.patch
Dropped, this was just test code
- 0010-vmbus-introduce-in-place-packet-iterator.patch
Already upstream: f3dd3f4797652("vmbus: introduce in-place packet iterator")
- 0011-hvsock-fix-a-race-in-hvs_stream_dequeue.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0012-hvsock-fix-vsock_dequeue-enqueue_accept-race.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0013-Drivers-hv-vmbus-Fix-rescind-handling.patch
From the 4.11 patches
- 0014-vmbus-fix-hv_percpu_channel_deq-enq-race.patch
From the 4.11 patches
- 0015-vmbus-add-vmbus-onoffer-onoffer_rescind-sync.patch
From the 4.11 patches
- 0016-hv-sock-a-temporary-workaround-for-the-pending_send_.patch
DROPPED. Does not apply at all anymore. Was a hack anyway
- 0017-vmbus-fix-the-missed-signaling-in-hv_signal_on_read.patch
Applied manually from the 4.11 patches
- 0018-hv-sock-avoid-double-FINs-if-shutdown-is-called.patch
From https://github.com/dcui/linux/commits/decui/msft-4.12.y
- 0019-Added-vsock-transport-support-to-9pfs.patch
From the 4.11 patches
- 0020-NVDIMM-reducded-ND_MIN_NAMESPACE_SIZE-from-4MB-to-4K.patch
From the 4.11 patches
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The host side VSOCK implementation introduced with
0009-VSOCK-Introduce-vhost_vsock.ko.patch
does not compile due to vhost_vq_init_access not being defined.
VHOST support (including VHOST_VSOCK) was enabled with
86deeaff ("kernel: Bring 4.4 x86_64 kernel config more in line
with 4.9") but not compile tested. Having VHOST support in
itself is fine, it's just the VHOST_VSOCK portion which is not
avail.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The kernel config for debug kernels is created by concatenating
config files, so we can't use diff to check it.
This fixes a regression introduced by:
9362de0a ("kernel: Verify kernel config")
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is based on the example, but modified so that it can work as a test.
It is slightly less convenient running services as tests as the output is
sent to log files, so we have an `onshutdown` container that checks to see
if the test passed.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This creates two containers connected over a Wireguard tunnel.
From the `getty` container that comes up you can connect to the
Nginx server via an encrypted tunnel with
```
wget -O - http://192.168.2.1
```
You can use `nsenter` to check out the other namespaces. There is no
external connectivity in either the `getty` or `nginx` containers,
so the only available networking is through the wireguard tunnel.
Signed-off-by: Justin Cormack <justin.cormack@docker.com>
- Update section on how to change the kernel config
- Reword kernel module section. It was messy
- General tidying up:
- empty lines around quoted areas
- two empty line above and one empty line below section headings
- Limit line length.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
