diff --git a/kernel/patches-4.4.x/0001-x86-microcode-intel-Avoid-division-by-zero.patch b/kernel/patches-4.4.x/0001-x86-microcode-intel-Avoid-division-by-zero.patch new file mode 100644 index 000000000..6468a782b --- /dev/null +++ b/kernel/patches-4.4.x/0001-x86-microcode-intel-Avoid-division-by-zero.patch @@ -0,0 +1,80 @@ +From 6b7e072829a8b4e8b3c19f01138998a5d74558cf Mon Sep 17 00:00:00 2001 +From: Rolf Neugebauer +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:[] [] 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] [] ? microcode_init+0x36/0x1de +[ 1.619264] [] ? set_debug_rodata+0xc/0xc +[ 1.620143] [] ? driver_register+0xaf/0xb4 +[ 1.621841] [] ? save_microcode_in_initrd+0x3c/0x3c +[ 1.623424] [] ? do_one_initcall+0x98/0x130 +[ 1.624659] [] ? set_debug_rodata+0xc/0xc +[ 1.626303] [] ? kernel_init_freeable+0x166/0x1e7 +[ 1.627674] [] ? rest_init+0x6e/0x6e +[ 1.628942] [] ? kernel_init+0xa/0xe6 +[ 1.630243] [] ? 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 [] init_intel_microcode+0x49/0x5a +[ 1.640382] RSP +[ 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 +--- + 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 + diff --git a/kernel/patches-4.9.x/0001-tools-build-Add-test-for-sched_getcpu.patch b/kernel/patches-4.9.x/0001-tools-build-Add-test-for-sched_getcpu.patch index 05eae75a8..7196565a3 100644 --- a/kernel/patches-4.9.x/0001-tools-build-Add-test-for-sched_getcpu.patch +++ b/kernel/patches-4.9.x/0001-tools-build-Add-test-for-sched_getcpu.patch @@ -1,7 +1,7 @@ From d249c8a91517af30e63a8abfa7ce7c6ad998d7b7 Mon Sep 17 00:00:00 2001 From: Arnaldo Carvalho de Melo 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 diff --git a/kernel/patches-4.9.x/0002-perf-jit-Avoid-returning-garbage-for-a-ret-variable.patch b/kernel/patches-4.9.x/0002-perf-jit-Avoid-returning-garbage-for-a-ret-variable.patch index 1c0869ab6..9c318ac11 100644 --- a/kernel/patches-4.9.x/0002-perf-jit-Avoid-returning-garbage-for-a-ret-variable.patch +++ b/kernel/patches-4.9.x/0002-perf-jit-Avoid-returning-garbage-for-a-ret-variable.patch @@ -1,7 +1,7 @@ From 8c548dd2caeed54dd02610cd4bae351b89682d8c Mon Sep 17 00:00:00 2001 From: Arnaldo Carvalho de Melo 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. diff --git a/kernel/patches-4.9.x/0003-hv_sock-introduce-Hyper-V-Sockets.patch b/kernel/patches-4.9.x/0003-hv_sock-introduce-Hyper-V-Sockets.patch index 4f79d6597..bf60c0042 100644 --- a/kernel/patches-4.9.x/0003-hv_sock-introduce-Hyper-V-Sockets.patch +++ b/kernel/patches-4.9.x/0003-hv_sock-introduce-Hyper-V-Sockets.patch @@ -1,7 +1,7 @@ From f350364380d1ad3cc73df12265c8b6476dfe51fa Mon Sep 17 00:00:00 2001 From: Dexuan Cui 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 diff --git a/kernel/patches-4.9.x/0004-vmbus-Don-t-spam-the-logs-with-unknown-GUIDs.patch b/kernel/patches-4.9.x/0004-vmbus-Don-t-spam-the-logs-with-unknown-GUIDs.patch index 03472890b..63892adf7 100644 --- a/kernel/patches-4.9.x/0004-vmbus-Don-t-spam-the-logs-with-unknown-GUIDs.patch +++ b/kernel/patches-4.9.x/0004-vmbus-Don-t-spam-the-logs-with-unknown-GUIDs.patch @@ -1,7 +1,7 @@ From c9e4562f53bd6a7276a2927b186d5b6bcefc9a78 Mon Sep 17 00:00:00 2001 From: Rolf Neugebauer 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 diff --git a/kernel/patches-4.9.x/0005-Drivers-hv-utils-Fix-the-mapping-between-host-versio.patch b/kernel/patches-4.9.x/0005-Drivers-hv-utils-Fix-the-mapping-between-host-versio.patch index d68841f13..4533a535c 100644 --- a/kernel/patches-4.9.x/0005-Drivers-hv-utils-Fix-the-mapping-between-host-versio.patch +++ b/kernel/patches-4.9.x/0005-Drivers-hv-utils-Fix-the-mapping-between-host-versio.patch @@ -1,7 +1,7 @@ From bfa241cc0ba86944ce412257f61d7397091dca50 Mon Sep 17 00:00:00 2001 From: Alex Ng 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 diff --git a/kernel/patches-4.9.x/0006-Drivers-hv-vss-Improve-log-messages.patch b/kernel/patches-4.9.x/0006-Drivers-hv-vss-Improve-log-messages.patch index 069e3a8bf..e6e4811a3 100644 --- a/kernel/patches-4.9.x/0006-Drivers-hv-vss-Improve-log-messages.patch +++ b/kernel/patches-4.9.x/0006-Drivers-hv-vss-Improve-log-messages.patch @@ -1,7 +1,7 @@ From e4e0219800f56fdabc70ab3979f1a4c47b2f6411 Mon Sep 17 00:00:00 2001 From: Alex Ng 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. diff --git a/kernel/patches-4.9.x/0007-Drivers-hv-vss-Operation-timeouts-should-match-host-.patch b/kernel/patches-4.9.x/0007-Drivers-hv-vss-Operation-timeouts-should-match-host-.patch index 989652e2c..8085e0fe7 100644 --- a/kernel/patches-4.9.x/0007-Drivers-hv-vss-Operation-timeouts-should-match-host-.patch +++ b/kernel/patches-4.9.x/0007-Drivers-hv-vss-Operation-timeouts-should-match-host-.patch @@ -1,7 +1,7 @@ From 1c376d4e0a67bd1e7f46e88eec3d2d38aa18c367 Mon Sep 17 00:00:00 2001 From: Alex Ng 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, diff --git a/kernel/patches-4.9.x/0008-Drivers-hv-vmbus-Use-all-supported-IC-versions-to-ne.patch b/kernel/patches-4.9.x/0008-Drivers-hv-vmbus-Use-all-supported-IC-versions-to-ne.patch index e57358b8a..85cf3e7a8 100644 --- a/kernel/patches-4.9.x/0008-Drivers-hv-vmbus-Use-all-supported-IC-versions-to-ne.patch +++ b/kernel/patches-4.9.x/0008-Drivers-hv-vmbus-Use-all-supported-IC-versions-to-ne.patch @@ -1,7 +1,7 @@ From 0620946a57585307071160fa5af71a23d3ff3a2c Mon Sep 17 00:00:00 2001 From: Alex Ng 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 diff --git a/kernel/patches-4.9.x/0009-Drivers-hv-Log-the-negotiated-IC-versions.patch b/kernel/patches-4.9.x/0009-Drivers-hv-Log-the-negotiated-IC-versions.patch index c62f13fdf..cf3871730 100644 --- a/kernel/patches-4.9.x/0009-Drivers-hv-Log-the-negotiated-IC-versions.patch +++ b/kernel/patches-4.9.x/0009-Drivers-hv-Log-the-negotiated-IC-versions.patch @@ -1,7 +1,7 @@ From 41ce4da3ddbf2eb9790738a479ec4e50db46eebb Mon Sep 17 00:00:00 2001 From: Alex Ng 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. diff --git a/kernel/patches-4.9.x/0010-vmbus-fix-missed-ring-events-on-boot.patch b/kernel/patches-4.9.x/0010-vmbus-fix-missed-ring-events-on-boot.patch index c8e1acd6f..66b5b6e50 100644 --- a/kernel/patches-4.9.x/0010-vmbus-fix-missed-ring-events-on-boot.patch +++ b/kernel/patches-4.9.x/0010-vmbus-fix-missed-ring-events-on-boot.patch @@ -1,7 +1,7 @@ From 3ffad6b5d1f3d4f0e49ea5eb352c97fb374c8aa0 Mon Sep 17 00:00:00 2001 From: Dexuan Cui 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 diff --git a/kernel/patches-4.9.x/0011-vmbus-remove-goto-error_clean_msglist-in-vmbus_open.patch b/kernel/patches-4.9.x/0011-vmbus-remove-goto-error_clean_msglist-in-vmbus_open.patch index 4fa0906f8..920961b2b 100644 --- a/kernel/patches-4.9.x/0011-vmbus-remove-goto-error_clean_msglist-in-vmbus_open.patch +++ b/kernel/patches-4.9.x/0011-vmbus-remove-goto-error_clean_msglist-in-vmbus_open.patch @@ -1,7 +1,7 @@ From 1794bf5e96cff6dfb433840ede089040753339a7 Mon Sep 17 00:00:00 2001 From: Dexuan Cui 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. diff --git a/kernel/patches-4.9.x/0012-vmbus-dynamically-enqueue-dequeue-the-channel-on-vmb.patch b/kernel/patches-4.9.x/0012-vmbus-dynamically-enqueue-dequeue-the-channel-on-vmb.patch index 11b17e453..bdb59deed 100644 --- a/kernel/patches-4.9.x/0012-vmbus-dynamically-enqueue-dequeue-the-channel-on-vmb.patch +++ b/kernel/patches-4.9.x/0012-vmbus-dynamically-enqueue-dequeue-the-channel-on-vmb.patch @@ -1,7 +1,7 @@ From 03bb29f91f12a6b134e632704aa5756ae5709f5d Mon Sep 17 00:00:00 2001 From: Dexuan Cui 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 diff --git a/kernel/patches-4.9.x/0013-x86-microcode-intel-Avoid-division-by-zero.patch b/kernel/patches-4.9.x/0013-x86-microcode-intel-Avoid-division-by-zero.patch new file mode 100644 index 000000000..5f08a18aa --- /dev/null +++ b/kernel/patches-4.9.x/0013-x86-microcode-intel-Avoid-division-by-zero.patch @@ -0,0 +1,80 @@ +From 5b1b8d01842d3e6799cf848519da43bc2a5d6edb Mon Sep 17 00:00:00 2001 +From: Rolf Neugebauer +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:[] [] 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] [] ? microcode_init+0x36/0x1de +[ 1.619264] [] ? set_debug_rodata+0xc/0xc +[ 1.620143] [] ? driver_register+0xaf/0xb4 +[ 1.621841] [] ? save_microcode_in_initrd+0x3c/0x3c +[ 1.623424] [] ? do_one_initcall+0x98/0x130 +[ 1.624659] [] ? set_debug_rodata+0xc/0xc +[ 1.626303] [] ? kernel_init_freeable+0x166/0x1e7 +[ 1.627674] [] ? rest_init+0x6e/0x6e +[ 1.628942] [] ? kernel_init+0xa/0xe6 +[ 1.630243] [] ? 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 [] init_intel_microcode+0x49/0x5a +[ 1.640382] RSP +[ 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 +--- + 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 +