Update AUFS kernel to 4.9

Signed-off-by: Justin Cormack <justin.cormack@docker.com>
This commit is contained in:
Justin Cormack 2016-12-21 19:55:11 +00:00
parent cc72074b11
commit f953ad780c
10 changed files with 10 additions and 1994 deletions

View File

@ -20,7 +20,7 @@ RUN if [ $DEBUG -ne "0" ]; then \
fi
# Apply local patches
COPY patches /patches
COPY patches-4.9 /patches
RUN cd /linux && \
set -e && for patch in /patches/*.patch; do \
echo "Applying $patch"; \

View File

@ -1,7 +1,7 @@
# Tag: 3da0b0ea0da2724232603094e67c75b41adab551
FROM mobylinux/alpine-build-c@sha256:0236d6599f6c8f7aa42829285e04202fbe99984df2818af0f5a453a59de8b090
ARG KERNEL_VERSION=4.8.15
ARG KERNEL_VERSION=4.9
ENV KERNEL_SOURCE=https://www.kernel.org/pub/linux/kernel/v4.x/linux-${KERNEL_VERSION}.tar.xz
@ -9,10 +9,10 @@ RUN curl -fsSL -o linux-${KERNEL_VERSION}.tar.xz ${KERNEL_SOURCE}
RUN cat linux-${KERNEL_VERSION}.tar.xz | tar --absolute-names -xJ && mv /linux-${KERNEL_VERSION} /linux
# this is aufs4.8 20161010
# this is aufs4.9 20161219
ENV AUFS_REPO https://github.com/sfjro/aufs4-standalone
ENV AUFS_BRANCH aufs4.8
ENV AUFS_COMMIT e9fd128dcb16167417683e199a5feb14f3c9eca8
ENV AUFS_BRANCH aufs4.9
ENV AUFS_COMMIT 0d8e71c28da317ec6371b6b95b46a70cefe13777
# Download AUFS
RUN git clone -b "$AUFS_BRANCH" "$AUFS_REPO" /aufs && \
@ -58,7 +58,7 @@ RUN if [ $DEBUG -ne "0" ]; then \
fi
# Apply local patches
COPY patches-aufs /patches
COPY patches-4.9 /patches
RUN cd /linux && \
set -e && for patch in /patches/*.patch; do \
echo "Applying $patch"; \

View File

@ -3,7 +3,7 @@ DEBUG ?= 0
all: x86_64/vmlinuz64
ifdef AUFS
x86_64/vmlinuz64: Dockerfile.aufs kernel_config kernel_config.debug kernel_config.aufs patches-aufs
x86_64/vmlinuz64: Dockerfile.aufs kernel_config kernel_config.debug kernel_config.aufs patches-4.9
mkdir -p x86_64 etc lib usr sbin
BUILD=$$( tar cf - $^ | docker build -f Dockerfile.aufs --build-arg DEBUG=$(DEBUG) -q - ) && [ -n "$$BUILD" ] && echo "Built $$BUILD" && \
docker run --rm --net=none --log-driver=none $$BUILD cat /kernel-modules.tar | tar xf - && \
@ -12,9 +12,9 @@ x86_64/vmlinuz64: Dockerfile.aufs kernel_config kernel_config.debug kernel_confi
docker run --rm --net=none --log-driver=none $$BUILD cat /linux/vmlinux > x86_64/vmlinux && \
docker run --rm --net=none --log-driver=none $$BUILD cat /linux/arch/x86_64/boot/bzImage > $@ && \
docker run --rm --net=none --log-driver=none $$BUILD cat /kernel-headers.tar > x86_64/kernel-headers.tar && \
cp -a patches-aufs etc/kernel-patches
cp -a patches-4.9 etc/kernel-patches
else
x86_64/vmlinuz64: Dockerfile kernel_config kernel_config.debug patches
x86_64/vmlinuz64: Dockerfile kernel_config kernel_config.debug patches-4.9
mkdir -p x86_64 etc lib usr sbin
BUILD=$$( tar cf - $^ | docker build --build-arg DEBUG=$(DEBUG) -q - ) && [ -n "$$BUILD" ] && echo "Built $$BUILD" && \
docker run --rm --net=none --log-driver=none $$BUILD cat /kernel-modules.tar | tar xf - && \
@ -22,7 +22,7 @@ x86_64/vmlinuz64: Dockerfile kernel_config kernel_config.debug patches
docker run --rm --net=none --log-driver=none $$BUILD cat /linux/vmlinux > x86_64/vmlinux && \
docker run --rm --net=none --log-driver=none $$BUILD cat /linux/arch/x86_64/boot/bzImage > $@ && \
docker run --rm --net=none --log-driver=none $$BUILD cat /kernel-headers.tar > x86_64/kernel-headers.tar && \
cp -a patches etc/kernel-patches
cp -a patches-4.9 etc/kernel-patches
endif
clean:

View File

@ -1,133 +0,0 @@
From 0ee181462b9f52d60ca5188e3013870621068864 Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@microsoft.com>
Date: Sat, 21 May 2016 16:55:50 +0800
Subject: [PATCH 2/5] Drivers: hv: vmbus: fix the race when querying & updating
the percpu list
There is a rare race when we remove an entry from the global list
hv_context.percpu_list[cpu] in hv_process_channel_removal() ->
percpu_channel_deq() -> list_del(): at this time, if vmbus_on_event() ->
process_chn_event() -> pcpu_relid2channel() is trying to query the list,
we can get the general protection fault:
general protection fault: 0000 [#1] SMP
...
RIP: 0010:[<ffffffff81461b6b>] [<ffffffff81461b6b>] vmbus_on_event+0xc4/0x149
Similarly, we also have the issue in the code path: vmbus_process_offer() ->
percpu_channel_enq().
We can resolve the issue by disabling the tasklet when updating the list.
Reported-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Origin: https://github.com/dcui/linux/commit/fbcca73228b9b90911ab30fdf75f532b2b7c07e5
---
drivers/hv/channel.c | 1 +
drivers/hv/channel_mgmt.c | 18 ++++++++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 56dd261..75343e0 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -592,6 +592,7 @@ static int vmbus_close_internal(struct vmbus_channel *channel)
out:
tasklet_enable(tasklet);
+ tasklet_schedule(tasklet);
return ret;
}
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index b6c1211..8f4e6070 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -21,6 +21,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/kernel.h>
+#include <linux/interrupt.h>
#include <linux/sched.h>
#include <linux/wait.h>
#include <linux/mm.h>
@@ -307,12 +308,13 @@ void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
{
unsigned long flags;
struct vmbus_channel *primary_channel;
-
- vmbus_release_relid(relid);
+ struct tasklet_struct *tasklet;
BUG_ON(!channel->rescind);
BUG_ON(!mutex_is_locked(&vmbus_connection.channel_mutex));
+ tasklet = hv_context.event_dpc[channel->target_cpu];
+ tasklet_disable(tasklet);
if (channel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(channel->target_cpu,
@@ -321,6 +323,8 @@ void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
percpu_channel_deq(channel);
put_cpu();
}
+ tasklet_enable(tasklet);
+ tasklet_schedule(tasklet);
if (channel->primary_channel == NULL) {
list_del(&channel->listentry);
@@ -342,6 +346,8 @@ void hv_process_channel_removal(struct vmbus_channel *channel, u32 relid)
&primary_channel->alloced_cpus_in_node);
free_channel(channel);
+
+ vmbus_release_relid(relid);
}
void vmbus_free_channels(void)
@@ -363,6 +369,7 @@ void vmbus_free_channels(void)
*/
static void vmbus_process_offer(struct vmbus_channel *newchannel)
{
+ struct tasklet_struct *tasklet;
struct vmbus_channel *channel;
bool fnew = true;
unsigned long flags;
@@ -409,6 +416,8 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
init_vp_index(newchannel, dev_type);
+ tasklet = hv_context.event_dpc[newchannel->target_cpu];
+ tasklet_disable(tasklet);
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
@@ -418,6 +427,8 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
percpu_channel_enq(newchannel);
put_cpu();
}
+ tasklet_enable(tasklet);
+ tasklet_schedule(tasklet);
/*
* This state is used to indicate a successful open
@@ -469,6 +480,7 @@ err_deq_chan:
list_del(&newchannel->listentry);
mutex_unlock(&vmbus_connection.channel_mutex);
+ tasklet_disable(tasklet);
if (newchannel->target_cpu != get_cpu()) {
put_cpu();
smp_call_function_single(newchannel->target_cpu,
@@ -477,6 +489,8 @@ err_deq_chan:
percpu_channel_deq(newchannel);
put_cpu();
}
+ tasklet_enable(tasklet);
+ tasklet_schedule(tasklet);
err_free_chan:
free_channel(newchannel);
--
2.10.2

View File

@ -1,30 +0,0 @@
From afc48615e62910f37b6076f9118c80d2f9613064 Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@docker.com>
Date: Mon, 4 Apr 2016 14:50:10 +0100
Subject: [PATCH 1/5] VSOCK: Only allow host network namespace to use AF_VSOCK.
The VSOCK addressing schema does not really lend itself to simply creating an
alternative end point address within a namespace.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
---
net/vmw_vsock/af_vsock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 8a398b3..0edc54c 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1852,6 +1852,9 @@ static const struct proto_ops vsock_stream_ops = {
static int vsock_create(struct net *net, struct socket *sock,
int protocol, int kern)
{
+ if (!net_eq(net, &init_net))
+ return -EAFNOSUPPORT;
+
if (!sock)
return -EINVAL;
--
2.10.2

View File

@ -1,30 +0,0 @@
From e8c7a6dee61819c36b77108bc2cddafde26b9876 Mon Sep 17 00:00:00 2001
From: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Date: Mon, 23 May 2016 18:55:45 +0100
Subject: [PATCH 4/5] vmbus: Don't spam the logs with unknown GUIDs
With Hyper-V sockets device types are introduced on the fly. The pr_info()
then prints a message on every connection, which is way too verbose. Since
there doesn't seem to be an easy way to check for registered services,
disable the pr_info() completely.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
---
drivers/hv/channel_mgmt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 8f4e6070..ef4a512 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -147,7 +147,6 @@ static u16 hv_get_dev_type(const uuid_le *guid)
if (!uuid_le_cmp(*guid, vmbus_devs[i].guid))
return i;
}
- pr_info("Unknown GUID: %pUl\n", guid);
return i;
}
--
2.10.2