github/linuxkit
1
0
Fork 0
mirror of https://github.com/linuxkit/linuxkit.git synced 2025-07-20 09:39:08 +00:00
Code Issues Projects Releases Wiki Activity

kernel: Add patch to prevent division by zero panic

Browse Source 
This adds a patch to avoid a division by zero panic for 4.4.x
and 4.9.x kernels on single vCPU machine types on Google Cloud.

4.14.x and 4.15.x kernels seem to work fine.

Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
This commit is contained in:
Rolf Neugebauer 2018-02-06 13:19:02 +00:00
parent 82f3f9ae9a
commit e4c4737548
14 changed files with 172 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
kernel/patches-4.4.x/0001-x86-microcode-intel-Avoid-division-by-zero.patch Normal file
View File

@ -0,0 +1,80 @@
From 6b7e072829a8b4e8b3c19f01138998a5d74558cf Mon Sep 17 00:00:00 2001
From: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Date: Tue, 6 Feb 2018 13:02:57 +0000
Subject: [PATCH] x86/microcode/intel: Avoid division by zero
The backport of 7e702d17ed1 ("x86/microcode/intel: Extend BDW
late-loading further with LLC size check") introduced a division
by zero panic on some platforms, specifically on machine types
with one vCPU on Google Cloud (e.g., g1-small and n1-standard-1):
[ 1.591435] divide error: 0000 [#1] SMP
[ 1.591961] Modules linked in:
[ 1.592546] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.79-linuxkit #1
[ 1.593461] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 1.595135] task: ffffa01b2b63c040 task.stack: ffffb24f40010000
[ 1.596683] RIP: 0010:[<ffffffffb7d88ce3>] [<ffffffffb7d88ce3>] init_intel_microcode+0x49/0x5a
[ 1.598018] RSP: 0000:ffffb24f40013e48 EFLAGS: 00010206
[ 1.599016] RAX: 0000000001400000 RBX: 00000000ffffffea RCX: 0000000000000000
[ 1.600093] RDX: 0000000000000000 RSI: ffffa01b2fffa9a8 RDI: ffffffffb7d8888b
[ 1.601222] RBP: 00000000ffffffff R08: ffffa01b2fffa9a1 R09: 000000000000005f
[ 1.602330] R10: 0000000000000067 R11: ffffa01b22164177 R12: 0000000000000000
[ 1.603291] R13: ffffffffb7d787b6 R14: 0000000000000000 R15: 0000000000000000
[ 1.604406] FS: 0000000000000000(0000) GS:ffffa01b2fc00000(0000) knlGS:0000000000000000
[ 1.606154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.607493] CR2: 0000000000000000 CR3: 000000002ac0a000 CR4: 0000000000040630
[ 1.609310] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1.611122] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1.613008] Stack:
[ 1.613445] ffffffffb7d888c1 0000000000000000 ffffffffb7d1ba40 0000000000000000
[ 1.615423] 0000000000000000 ffffffffb7d787b6 0000000000000000 0000000000000000
[ 1.617049] ffffffffb74fed89 00000000fffffff4 00000000ffffffff 4eae7bc133547c47
[ 1.617904] Call Trace:
[ 1.618198] [<ffffffffb7d888c1>] ? microcode_init+0x36/0x1de
[ 1.619264] [<ffffffffb7d787b6>] ? set_debug_rodata+0xc/0xc
[ 1.620143] [<ffffffffb74fed89>] ? driver_register+0xaf/0xb4
[ 1.621841] [<ffffffffb7d8888b>] ? save_microcode_in_initrd+0x3c/0x3c
[ 1.623424] [<ffffffffb70021b7>] ? do_one_initcall+0x98/0x130
[ 1.624659] [<ffffffffb7d787b6>] ? set_debug_rodata+0xc/0xc
[ 1.626303] [<ffffffffb7d79091>] ? kernel_init_freeable+0x166/0x1e7
[ 1.627674] [<ffffffffb77ce3d7>] ? rest_init+0x6e/0x6e
[ 1.628942] [<ffffffffb77ce3e1>] ? kernel_init+0xa/0xe6
[ 1.630243] [<ffffffffb77d8587>] ? ret_from_fork+0x57/0x70
[ 1.631592] Code: 16 0f b6 35 a0 ac fb ff 48 c7 c7 c4 ea 99 b7 e8 82 3e 41 ff 31 c0 c3 8b 05 3b ad fb ff 0f b7 0d 54 ad fb ff 31 d2 c1 e0 0a 48 98 <48> f7 f1 89 05 f4 6a 14 00 48 c7 c0 00 d8 c2 b7 c3 4c 8d 54 24
[ 1.638875] RIP [<ffffffffb7d88ce3>] init_intel_microcode+0x49/0x5a
[ 1.640382] RSP <ffffb24f40013e48>
[ 1.641320] ---[ end trace e88ef332e19594b9 ]---
[ 1.642418] Kernel panic - not syncing: Fatal exception
[ 1.644581] Kernel Offset: 0x36000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 1.647312] ---[ end Kernel panic - not syncing: Fatal exception
On these platforms x86_max_cores is 0:
[ 0.227977] ftrace: allocating 35563 entries in 139 pages
[ 0.273941] smpboot: x86_max_cores == zero !?!?
[ 0.274645] smpboot: Max logical packages: 1
Here, we check x86_max_core before calculating the llc_size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
---
arch/x86/kernel/cpu/microcode/intel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 2c76a1801393..2a581170ac0b 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -1077,6 +1077,9 @@ static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c)
{
u64 llc_size = c->x86_cache_size * 1024;
+ if (!c->x86_max_cores)
+ return 0;
+
do_div(llc_size, c->x86_max_cores);
return (int)llc_size;
--
2.16.0

2
kernel/patches-4.9.x/0001-tools-build-Add-test-for-sched_getcpu.patch
View File

@ -1,7 +1,7 @@
From d249c8a91517af30e63a8abfa7ce7c6ad998d7b7 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu, 2 Mar 2017 12:55:49 -0300
Subject: [PATCH 01/12] tools build: Add test for sched_getcpu()
Subject: [PATCH 01/13] tools build: Add test for sched_getcpu()
Instead of trying to go on adding more ifdef conditions, do a feature
test and define HAVE_SCHED_GETCPU_SUPPORT instead, then use it to

2
kernel/patches-4.9.x/0002-perf-jit-Avoid-returning-garbage-for-a-ret-variable.patch
View File

@ -1,7 +1,7 @@
From 8c548dd2caeed54dd02610cd4bae351b89682d8c Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo <acme@redhat.com>
Date: Thu, 13 Oct 2016 17:12:35 -0300
Subject: [PATCH 02/12] perf jit: Avoid returning garbage for a ret variable
Subject: [PATCH 02/13] perf jit: Avoid returning garbage for a ret variable
When the loop body isn't executed at all, then the 'ret' local variable,
that is uninitialized will be used as the return value.

2
kernel/patches-4.9.x/0003-hv_sock-introduce-Hyper-V-Sockets.patch
View File

@ -1,7 +1,7 @@
From f350364380d1ad3cc73df12265c8b6476dfe51fa Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@microsoft.com>
Date: Sat, 23 Jul 2016 01:35:51 +0000
Subject: [PATCH 03/12] hv_sock: introduce Hyper-V Sockets
Subject: [PATCH 03/13] hv_sock: introduce Hyper-V Sockets
Hyper-V Sockets (hv_sock) supplies a byte-stream based communication
mechanism between the host and the guest. It's somewhat like TCP over

2
kernel/patches-4.9.x/0004-vmbus-Don-t-spam-the-logs-with-unknown-GUIDs.patch
View File

@ -1,7 +1,7 @@
From c9e4562f53bd6a7276a2927b186d5b6bcefc9a78 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 04/12] vmbus: Don't spam the logs with unknown GUIDs
Subject: [PATCH 04/13] 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

2
kernel/patches-4.9.x/0005-Drivers-hv-utils-Fix-the-mapping-between-host-versio.patch
View File

@ -1,7 +1,7 @@
From bfa241cc0ba86944ce412257f61d7397091dca50 Mon Sep 17 00:00:00 2001
From: Alex Ng <alexng@messages.microsoft.com>
Date: Sun, 6 Nov 2016 13:14:07 -0800
Subject: [PATCH 05/12] Drivers: hv: utils: Fix the mapping between host
Subject: [PATCH 05/13] Drivers: hv: utils: Fix the mapping between host
version and protocol to use
We should intentionally declare the protocols to use for every known host

2
kernel/patches-4.9.x/0006-Drivers-hv-vss-Improve-log-messages.patch
View File

@ -1,7 +1,7 @@
From e4e0219800f56fdabc70ab3979f1a4c47b2f6411 Mon Sep 17 00:00:00 2001
From: Alex Ng <alexng@messages.microsoft.com>
Date: Sun, 6 Nov 2016 13:14:10 -0800
Subject: [PATCH 06/12] Drivers: hv: vss: Improve log messages.
Subject: [PATCH 06/13] Drivers: hv: vss: Improve log messages.
Adding log messages to help troubleshoot error cases and transaction
handling.

2
kernel/patches-4.9.x/0007-Drivers-hv-vss-Operation-timeouts-should-match-host-.patch
View File

@ -1,7 +1,7 @@
From 1c376d4e0a67bd1e7f46e88eec3d2d38aa18c367 Mon Sep 17 00:00:00 2001
From: Alex Ng <alexng@messages.microsoft.com>
Date: Sun, 6 Nov 2016 13:14:11 -0800
Subject: [PATCH 07/12] Drivers: hv: vss: Operation timeouts should match host
Subject: [PATCH 07/13] Drivers: hv: vss: Operation timeouts should match host
expectation
Increase the timeout of backup operations. When system is under I/O load,

2
kernel/patches-4.9.x/0008-Drivers-hv-vmbus-Use-all-supported-IC-versions-to-ne.patch
View File

@ -1,7 +1,7 @@
From 0620946a57585307071160fa5af71a23d3ff3a2c Mon Sep 17 00:00:00 2001
From: Alex Ng <alexng@messages.microsoft.com>
Date: Sat, 28 Jan 2017 12:37:17 -0700
Subject: [PATCH 08/12] Drivers: hv: vmbus: Use all supported IC versions to
Subject: [PATCH 08/13] Drivers: hv: vmbus: Use all supported IC versions to
negotiate
Previously, we were assuming that each IC protocol version was tied to a

2
kernel/patches-4.9.x/0009-Drivers-hv-Log-the-negotiated-IC-versions.patch
View File

@ -1,7 +1,7 @@
From 41ce4da3ddbf2eb9790738a479ec4e50db46eebb Mon Sep 17 00:00:00 2001
From: Alex Ng <alexng@messages.microsoft.com>
Date: Sat, 28 Jan 2017 12:37:18 -0700
Subject: [PATCH 09/12] Drivers: hv: Log the negotiated IC versions.
Subject: [PATCH 09/13] Drivers: hv: Log the negotiated IC versions.
Log the negotiated IC versions.

2
kernel/patches-4.9.x/0010-vmbus-fix-missed-ring-events-on-boot.patch
View File

@ -1,7 +1,7 @@
From 3ffad6b5d1f3d4f0e49ea5eb352c97fb374c8aa0 Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@microsoft.com>
Date: Sun, 26 Mar 2017 16:42:20 +0800
Subject: [PATCH 10/12] vmbus: fix missed ring events on boot
Subject: [PATCH 10/13] vmbus: fix missed ring events on boot
During initialization, the channel initialization code schedules the
tasklet to scan the VMBUS receive event page (i.e. simulates an

2
kernel/patches-4.9.x/0011-vmbus-remove-goto-error_clean_msglist-in-vmbus_open.patch
View File

@ -1,7 +1,7 @@
From 1794bf5e96cff6dfb433840ede089040753339a7 Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@microsoft.com>
Date: Wed, 29 Mar 2017 18:37:10 +0800
Subject: [PATCH 11/12] vmbus: remove "goto error_clean_msglist" in
Subject: [PATCH 11/13] vmbus: remove "goto error_clean_msglist" in
vmbus_open()
This is just a cleanup patch to simplify the code a little.

2
kernel/patches-4.9.x/0012-vmbus-dynamically-enqueue-dequeue-the-channel-on-vmb.patch
View File

@ -1,7 +1,7 @@
From 03bb29f91f12a6b134e632704aa5756ae5709f5d Mon Sep 17 00:00:00 2001
From: Dexuan Cui <decui@microsoft.com>
Date: Fri, 24 Mar 2017 20:53:18 +0800
Subject: [PATCH 12/12] vmbus: dynamically enqueue/dequeue the channel on
Subject: [PATCH 12/13] vmbus: dynamically enqueue/dequeue the channel on
vmbus_open/close
Signed-off-by: Dexuan Cui <decui@microsoft.com>

80
kernel/patches-4.9.x/0013-x86-microcode-intel-Avoid-division-by-zero.patch Normal file
View File

@ -0,0 +1,80 @@
From 5b1b8d01842d3e6799cf848519da43bc2a5d6edb Mon Sep 17 00:00:00 2001
From: Rolf Neugebauer <rolf.neugebauer@gmail.com>
Date: Tue, 6 Feb 2018 13:02:57 +0000
Subject: [PATCH 13/13] x86/microcode/intel: Avoid division by zero
The backport of 7e702d17ed1 ("x86/microcode/intel: Extend BDW
late-loading further with LLC size check") introduced a division
by zero panic on some platforms, specifically on machine types
with one vCPU on Google Cloud (e.g., g1-small and n1-standard-1):
[ 1.591435] divide error: 0000 [#1] SMP
[ 1.591961] Modules linked in:
[ 1.592546] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.79-linuxkit #1
[ 1.593461] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 1.595135] task: ffffa01b2b63c040 task.stack: ffffb24f40010000
[ 1.596683] RIP: 0010:[<ffffffffb7d88ce3>] [<ffffffffb7d88ce3>] init_intel_microcode+0x49/0x5a
[ 1.598018] RSP: 0000:ffffb24f40013e48 EFLAGS: 00010206
[ 1.599016] RAX: 0000000001400000 RBX: 00000000ffffffea RCX: 0000000000000000
[ 1.600093] RDX: 0000000000000000 RSI: ffffa01b2fffa9a8 RDI: ffffffffb7d8888b
[ 1.601222] RBP: 00000000ffffffff R08: ffffa01b2fffa9a1 R09: 000000000000005f
[ 1.602330] R10: 0000000000000067 R11: ffffa01b22164177 R12: 0000000000000000
[ 1.603291] R13: ffffffffb7d787b6 R14: 0000000000000000 R15: 0000000000000000
[ 1.604406] FS: 0000000000000000(0000) GS:ffffa01b2fc00000(0000) knlGS:0000000000000000
[ 1.606154] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.607493] CR2: 0000000000000000 CR3: 000000002ac0a000 CR4: 0000000000040630
[ 1.609310] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1.611122] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1.613008] Stack:
[ 1.613445] ffffffffb7d888c1 0000000000000000 ffffffffb7d1ba40 0000000000000000
[ 1.615423] 0000000000000000 ffffffffb7d787b6 0000000000000000 0000000000000000
[ 1.617049] ffffffffb74fed89 00000000fffffff4 00000000ffffffff 4eae7bc133547c47
[ 1.617904] Call Trace:
[ 1.618198] [<ffffffffb7d888c1>] ? microcode_init+0x36/0x1de
[ 1.619264] [<ffffffffb7d787b6>] ? set_debug_rodata+0xc/0xc
[ 1.620143] [<ffffffffb74fed89>] ? driver_register+0xaf/0xb4
[ 1.621841] [<ffffffffb7d8888b>] ? save_microcode_in_initrd+0x3c/0x3c
[ 1.623424] [<ffffffffb70021b7>] ? do_one_initcall+0x98/0x130
[ 1.624659] [<ffffffffb7d787b6>] ? set_debug_rodata+0xc/0xc
[ 1.626303] [<ffffffffb7d79091>] ? kernel_init_freeable+0x166/0x1e7
[ 1.627674] [<ffffffffb77ce3d7>] ? rest_init+0x6e/0x6e
[ 1.628942] [<ffffffffb77ce3e1>] ? kernel_init+0xa/0xe6
[ 1.630243] [<ffffffffb77d8587>] ? ret_from_fork+0x57/0x70
[ 1.631592] Code: 16 0f b6 35 a0 ac fb ff 48 c7 c7 c4 ea 99 b7 e8 82 3e 41 ff 31 c0 c3 8b 05 3b ad fb ff 0f b7 0d 54 ad fb ff 31 d2 c1 e0 0a 48 98 <48> f7 f1 89 05 f4 6a 14 00 48 c7 c0 00 d8 c2 b7 c3 4c 8d 54 24
[ 1.638875] RIP [<ffffffffb7d88ce3>] init_intel_microcode+0x49/0x5a
[ 1.640382] RSP <ffffb24f40013e48>
[ 1.641320] ---[ end trace e88ef332e19594b9 ]---
[ 1.642418] Kernel panic - not syncing: Fatal exception
[ 1.644581] Kernel Offset: 0x36000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 1.647312] ---[ end Kernel panic - not syncing: Fatal exception
On these platforms x86_max_cores is 0:
[ 0.227977] ftrace: allocating 35563 entries in 139 pages
[ 0.273941] smpboot: x86_max_cores == zero !?!?
[ 0.274645] smpboot: Max logical packages: 1
Here, we check x86_max_core before calculating the llc_size.
Signed-off-by: Rolf Neugebauer <rolf.neugebauer@docker.com>
---
arch/x86/kernel/cpu/microcode/intel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index f90f17610f62..a5dd9e5db4ce 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -1134,6 +1134,9 @@ static int __init calc_llc_size_per_core(struct cpuinfo_x86 *c)
{
u64 llc_size = c->x86_cache_size * 1024;
+ if (!c->x86_max_cores)
+ return 0;
+
do_div(llc_size, c->x86_max_cores);
return (int)llc_size;
--
2.16.0