AUFS introduces new lockdep relations which are beyond the maximum variants
that lockdep ships with. Without this patch, AUFS triggers lockdep BUG sanity
checks and disables lockdep for the rest of the system.
The present value of the patch is:
```diff
aufs4.4 lockdep patch
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index c57e424..4153563 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -29,7 +29,7 @@ extern int lock_stat;
*/
#define XXX_LOCK_USAGE_STATES (1+3*4)
-#define MAX_LOCKDEP_SUBCLASSES 8UL
+#define MAX_LOCKDEP_SUBCLASSES (8UL + 4)
/*
* NR_LOCKDEP_CACHING_CLASSES ... Number of classes
@@ -203,7 +203,7 @@ struct lock_chain {
u64 chain_key;
};
-#define MAX_LOCKDEP_KEYS_BITS 13
+#define MAX_LOCKDEP_KEYS_BITS (13 + 3)
/*
* Subtract one because we offset hlock->class_idx by 1 in order
* to make 0 mean no class. This avoids overflowing the class_idx
diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index 51c4b24..fba7557 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -54,9 +54,9 @@ enum {
* table (if it's not there yet), and we check it for lock order
* conflicts and deadlocks.
*/
-#define MAX_LOCKDEP_ENTRIES 32768UL
+#define MAX_LOCKDEP_ENTRIES (32768UL << 5)
-#define MAX_LOCKDEP_CHAINS_BITS 16
+#define MAX_LOCKDEP_CHAINS_BITS (16 + 5)
#define MAX_LOCKDEP_CHAINS (1UL << MAX_LOCKDEP_CHAINS_BITS)
#define MAX_LOCKDEP_CHAIN_HLOCKS (MAX_LOCKDEP_CHAINS*5)
@@ -65,7 +65,7 @@ enum {
* Stack-trace: tightly packed array of stack backtrace
* addresses. Protected by the hash_lock.
*/
-#define MAX_STACK_TRACE_ENTRIES 524288UL
+#define MAX_STACK_TRACE_ENTRIES (524288UL << 5)
extern struct list_head all_lock_classes;
extern struct lock_chain lock_chains[];
```
Signed-off-by: David Sheets <dsheets@docker.com>
- create an empty dummy file to indicate that docker image is built
- reuse same make rule to extract the different files from docker image
- make sure that we remove empty files on failure
This makes build more robust and improves parallelism.
Signed-off-by: Natanael Copa <natanael.copa@docker.com>
The ability to unload kernel modules helps with rapid development of kernel
modules or Moby-integrated functionality. It has no negative side effects
as far as I am aware.
Signed-off-by: David Sheets <dsheets@docker.com>
When we updated from 4.4.10 to 4.4.14 we copied the patches over.
This changeset properly updates the patches so that they apply cleanly.
0039-VSOCK-do-not-disconnect-socket-when-peer-has-shutdow.patch was
removed as it made it into 4.4.14 already.
Compile tested only
For reference the patches were generated from:
https://github.com/rneugeba/linux-stable/tree/v4.4.14-moby
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This is less to do with installing modules (which we generally don't expect to
use in Moby) but to populate /lib/modules/`uname -r`/modules.builtin which
turns:
moby:~# modprobe ip_vs
modprobe: FATAL: Module ip_vs not found in directory /lib/modules/4.4.14-moby
moby:~# modprobe nf_nat
modprobe: FATAL: Module nf_nat not found in directory /lib/modules/4.4.14-moby
moby:~#
into:
moby:~# modprobe ip_vs
moby:~# modprobe nf_nat
moby:~#
which reduces the amount noise in the logs, e.g. in docker.log:
time="2016-07-04T11:21:58Z" level=warning msg="Running modprobe nf_nat failed with message: `modprobe: WARNING: Module nf_nat not found in directory /lib/modules/4.4.14-moby`, error: exit status 1"
A fair number of these appear in the logs.
This also stops various tools logging about /lib/modules/`uname -r` not
existing (there was one in the boot log until recently I think)
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Increase the number of hypervisors where Moby can run and detect
the disks. With this change, I'm able to boot under KVM and see
the disk detected, formatted and mounted as expected.
When running moby under other hypervisors, requiring troubleshooting on
the serial port can be painful. This change enables console support on
tty1 similar to the way prior boot2docker images worked.
Linux xargs calls the command with no arguments if it gets no inputs, which
`docker rmi` complains about. It provides -r / --no-run-if-empty to prevent
this but unfortunately this isn't supported on OSX.
Ignore errors from `docker rmi` so that `make clean` will keep going and clean
up later stuff.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Added a patch to reduce verbosity of vmbus for unknown GUIDs.
Thes happen on every Hyper-V socket connection.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
DOS filesystems are handy for embedded development. ISO FS was
requested/suggested somewhere on a forum.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
These are most of the changes to channel.c and channel_mgmt.c from upstream.
They are needed to apply a proposed patch to fix yet another kernel crash
we reported. This patch is also included.
With these patches applied many thousand connections with random data and up
to 10 concurrent connections are sustained without kernel crashes.
This patch also updates the core Hyper-V socket support to v11 (which
also obsoletes the previous patch added to work around a kernel bug)
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
The Hyper-V socket patch has a bug which was triggered by a race condition when
the client connected and then immediately closed the connection before the
server would call accept(). This caused a kernel crash.
This patch was discussed with Dexuan Cui <decui@microsoft.com>, the original
author of the Hyper-V socket support.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This required pulling in the Qualcom IPC patches as those changed
the socket family enumeration.
All other patches should be the same.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
No practical change, but adds the "cherry-picked from" to aid tracking. This
has also been queued for stable so will eventually show up in a 4.4.x and can
be dropped from here.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Upstream commit 598881800825 ("vsock: Fix blocking ops call in
prepare_to_wait") was subsequently reverted in 6f57e56a1527, which said:
The commit reverted with this patch caused us to potentially miss wakeups.
Since the condition is not checked between the prepare_to_wait and the
schedule(), if a wakeup happens after the condition is checked but before
the sleep happens, we will miss it. ( A description of the problem can be
found here: http://www.makelinux.net/ldd3/chp-6-sect-2 ).
The underlying issue has been fixed instead with f7f9b5e7f8ec ("AF_VSOCK:
Shrink the area influenced by prepare_to_wait").
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
These are WIP taken from git@github.com:stefanha/linux.git#vsock
(==4c9d2a6be1c6, using "cherry-pick -x") and correspond to RFC v5 of the
frontend patches posted in
http://thread.gmane.org/gmane.linux.kernel.virtualization/27455
There is no corresponding spec proposal update yet, but this set of patches
correspond (roughly) to addressing the feedback on v4 of the spec proposal
http://thread.gmane.org/gmane.comp.emulators.virtio.devel/1062.
kernel_config.arm modifications copied from x86, not tested.
Added /etc/kernel-patches/ directory to the image to be consumed by the
licensing.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
