From: Greg Kroah-Hartman Date: Mon, 30 Apr 2018 00:03:55 +0000 (-0700) Subject: 4.16-stable patches X-Git-Tag: v4.16.7~13 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bbde174781bb0aeac1e834950bd2fb5ffe7d6f17;p=thirdparty%2Fkernel%2Fstable-queue.git 4.16-stable patches added patches: tick-sched-do-not-mess-with-an-enqueued-hrtimer.patch x86-ipc-fix-x32-version-of-shmid64_ds-and-msqid64_ds.patch x86-microcode-do-not-exit-early-from-__reload_late.patch x86-microcode-intel-save-microcode-patch-unconditionally.patch x86-smpboot-don-t-use-mwait_play_dead-on-amd-systems.patch --- diff --git a/queue-4.16/series b/queue-4.16/series index e5e8d1a9150..0613e3504f1 100644 --- a/queue-4.16/series +++ b/queue-4.16/series @@ -104,3 +104,8 @@ drm-amd-display-fix-deadlock-when-flushing-irq.patch drm-amd-display-don-t-read-edid-in-atomic_check.patch drm-amd-display-disallow-enabling-crtc-without-primary-plane-with-fb.patch objtool-perf-fix-gcc-8-wrestrict-error.patch +x86-ipc-fix-x32-version-of-shmid64_ds-and-msqid64_ds.patch +x86-smpboot-don-t-use-mwait_play_dead-on-amd-systems.patch +x86-microcode-intel-save-microcode-patch-unconditionally.patch +x86-microcode-do-not-exit-early-from-__reload_late.patch +tick-sched-do-not-mess-with-an-enqueued-hrtimer.patch diff --git a/queue-4.16/tick-sched-do-not-mess-with-an-enqueued-hrtimer.patch b/queue-4.16/tick-sched-do-not-mess-with-an-enqueued-hrtimer.patch new file mode 100644 index 00000000000..98e0e7a2aee --- /dev/null +++ b/queue-4.16/tick-sched-do-not-mess-with-an-enqueued-hrtimer.patch @@ -0,0 +1,99 @@ +From 1f71addd34f4c442bec7d7c749acc1beb58126f2 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 24 Apr 2018 21:22:18 +0200 +Subject: tick/sched: Do not mess with an enqueued hrtimer + +From: Thomas Gleixner + +commit 1f71addd34f4c442bec7d7c749acc1beb58126f2 upstream. + +Kaike reported that in tests rdma hrtimers occasionaly stopped working. He +did great debugging, which provided enough context to decode the problem. + +CPU 3 CPU 2 + +idle +start sched_timer expires = 712171000000 + queue->next = sched_timer + start rdmavt timer. expires = 712172915662 + lock(baseof(CPU3)) +tick_nohz_stop_tick() +tick = 716767000000 timerqueue_add(tmr) + +hrtimer_set_expires(sched_timer, tick); + sched_timer->expires = 716767000000 <---- FAIL + if (tmr->expires < queue->next->expires) +hrtimer_start(sched_timer) queue->next = tmr; +lock(baseof(CPU3)) + unlock(baseof(CPU3)) +timerqueue_remove() +timerqueue_add() + +ts->sched_timer is queued and queue->next is pointing to it, but then +ts->sched_timer.expires is modified. + +This not only corrupts the ordering of the timerqueue RB tree, it also +makes CPU2 see the new expiry time of timerqueue->next->expires when +checking whether timerqueue->next needs to be updated. So CPU2 sees that +the rdma timer is earlier than timerqueue->next and sets the rdma timer as +new next. + +Depending on whether it had also seen the new time at RB tree enqueue, it +might have queued the rdma timer at the wrong place and then after removing +the sched_timer the RB tree is completely hosed. + +The problem was introduced with a commit which tried to solve inconsistency +between the hrtimer in the tick_sched data and the underlying hardware +clockevent. It split out hrtimer_set_expires() to store the new tick time +in both the NOHZ and the NOHZ + HIGHRES case, but missed the fact that in +the NOHZ + HIGHRES case the hrtimer might still be queued. + +Use hrtimer_start(timer, tick...) for the NOHZ + HIGHRES case which sets +timer->expires after canceling the timer and move the hrtimer_set_expires() +invocation into the NOHZ only code path which is not affected as it merily +uses the hrtimer as next event storage so code pathes can be shared with +the NOHZ + HIGHRES case. + +Fixes: d4af6d933ccf ("nohz: Fix spurious warning when hrtimer and clockevent get out of sync") +Reported-by: "Wan Kaike" +Signed-off-by: Thomas Gleixner +Acked-by: Frederic Weisbecker +Cc: "Marciniszyn Mike" +Cc: Anna-Maria Gleixner +Cc: linux-rdma@vger.kernel.org +Cc: "Dalessandro Dennis" +Cc: "Fleck John" +Cc: stable@vger.kernel.org +Cc: Peter Zijlstra +Cc: Frederic Weisbecker +Cc: "Weiny Ira" +Cc: "linux-rdma@vger.kernel.org" +Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804241637390.1679@nanos.tec.linutronix.de +Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1804242119210.1597@nanos.tec.linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/tick-sched.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/kernel/time/tick-sched.c ++++ b/kernel/time/tick-sched.c +@@ -797,12 +797,13 @@ static ktime_t tick_nohz_stop_sched_tick + goto out; + } + +- hrtimer_set_expires(&ts->sched_timer, tick); +- +- if (ts->nohz_mode == NOHZ_MODE_HIGHRES) +- hrtimer_start_expires(&ts->sched_timer, HRTIMER_MODE_ABS_PINNED); +- else ++ if (ts->nohz_mode == NOHZ_MODE_HIGHRES) { ++ hrtimer_start(&ts->sched_timer, tick, HRTIMER_MODE_ABS_PINNED); ++ } else { ++ hrtimer_set_expires(&ts->sched_timer, tick); + tick_program_event(tick, 1); ++ } ++ + out: + /* + * Update the estimated sleep length until the next timer diff --git a/queue-4.16/x86-ipc-fix-x32-version-of-shmid64_ds-and-msqid64_ds.patch b/queue-4.16/x86-ipc-fix-x32-version-of-shmid64_ds-and-msqid64_ds.patch new file mode 100644 index 00000000000..63f079d72d2 --- /dev/null +++ b/queue-4.16/x86-ipc-fix-x32-version-of-shmid64_ds-and-msqid64_ds.patch @@ -0,0 +1,128 @@ +From 1a512c0882bd311c5b5561840fcfbe4c25b8f319 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Tue, 24 Apr 2018 23:19:51 +0200 +Subject: x86/ipc: Fix x32 version of shmid64_ds and msqid64_ds + +From: Arnd Bergmann + +commit 1a512c0882bd311c5b5561840fcfbe4c25b8f319 upstream. + +A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout +(as seen from user space) a few years ago: Originally, __BITS_PER_LONG +was defined as 64 on x32, so we did not have padding after the 64-bit +__kernel_time_t fields, After __BITS_PER_LONG got changed to 32, +applications would observe extra padding. + +In other parts of the uapi headers we seem to have a mix of those +expecting either 32 or 64 on x32 applications, so we can't easily revert +the path that broke these two structures. + +Instead, this patch decouples x32 from the other architectures and moves +it back into arch specific headers, partially reverting the even older +commit 73a2d096fdf2 ("x86: remove all now-duplicate header files"). + +It's not clear whether this ever made any difference, since at least +glibc carries its own (correct) copy of both of these header files, +so possibly no application has ever observed the definitions here. + +Based on a suggestion from H.J. Lu, I tried out the tool from +https://github.com/hjl-tools/linux-header to find other such +bugs, which pointed out the same bug in statfs(), which also has +a separate (correct) copy in glibc. + +Fixes: f4b4aae18288 ("x86/headers/uapi: Fix __BITS_PER_LONG value for x32 builds") +Signed-off-by: Arnd Bergmann +Signed-off-by: Thomas Gleixner +Cc: "H . J . Lu" +Cc: Jeffrey Walton +Cc: stable@vger.kernel.org +Cc: "H. Peter Anvin" +Link: https://lkml.kernel.org/r/20180424212013.3967461-1-arnd@arndb.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/uapi/asm/msgbuf.h | 31 +++++++++++++++++++++++++++ + arch/x86/include/uapi/asm/shmbuf.h | 42 +++++++++++++++++++++++++++++++++++++ + 2 files changed, 73 insertions(+) + +--- a/arch/x86/include/uapi/asm/msgbuf.h ++++ b/arch/x86/include/uapi/asm/msgbuf.h +@@ -1 +1,32 @@ ++/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ ++#ifndef __ASM_X64_MSGBUF_H ++#define __ASM_X64_MSGBUF_H ++ ++#if !defined(__x86_64__) || !defined(__ILP32__) + #include ++#else ++/* ++ * The msqid64_ds structure for x86 architecture with x32 ABI. ++ * ++ * On x86-32 and x86-64 we can just use the generic definition, but ++ * x32 uses the same binary layout as x86_64, which is differnet ++ * from other 32-bit architectures. ++ */ ++ ++struct msqid64_ds { ++ struct ipc64_perm msg_perm; ++ __kernel_time_t msg_stime; /* last msgsnd time */ ++ __kernel_time_t msg_rtime; /* last msgrcv time */ ++ __kernel_time_t msg_ctime; /* last change time */ ++ __kernel_ulong_t msg_cbytes; /* current number of bytes on queue */ ++ __kernel_ulong_t msg_qnum; /* number of messages in queue */ ++ __kernel_ulong_t msg_qbytes; /* max number of bytes on queue */ ++ __kernel_pid_t msg_lspid; /* pid of last msgsnd */ ++ __kernel_pid_t msg_lrpid; /* last receive pid */ ++ __kernel_ulong_t __unused4; ++ __kernel_ulong_t __unused5; ++}; ++ ++#endif ++ ++#endif /* __ASM_GENERIC_MSGBUF_H */ +--- a/arch/x86/include/uapi/asm/shmbuf.h ++++ b/arch/x86/include/uapi/asm/shmbuf.h +@@ -1 +1,43 @@ ++/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ ++#ifndef __ASM_X86_SHMBUF_H ++#define __ASM_X86_SHMBUF_H ++ ++#if !defined(__x86_64__) || !defined(__ILP32__) + #include ++#else ++/* ++ * The shmid64_ds structure for x86 architecture with x32 ABI. ++ * ++ * On x86-32 and x86-64 we can just use the generic definition, but ++ * x32 uses the same binary layout as x86_64, which is differnet ++ * from other 32-bit architectures. ++ */ ++ ++struct shmid64_ds { ++ struct ipc64_perm shm_perm; /* operation perms */ ++ size_t shm_segsz; /* size of segment (bytes) */ ++ __kernel_time_t shm_atime; /* last attach time */ ++ __kernel_time_t shm_dtime; /* last detach time */ ++ __kernel_time_t shm_ctime; /* last change time */ ++ __kernel_pid_t shm_cpid; /* pid of creator */ ++ __kernel_pid_t shm_lpid; /* pid of last operator */ ++ __kernel_ulong_t shm_nattch; /* no. of current attaches */ ++ __kernel_ulong_t __unused4; ++ __kernel_ulong_t __unused5; ++}; ++ ++struct shminfo64 { ++ __kernel_ulong_t shmmax; ++ __kernel_ulong_t shmmin; ++ __kernel_ulong_t shmmni; ++ __kernel_ulong_t shmseg; ++ __kernel_ulong_t shmall; ++ __kernel_ulong_t __unused1; ++ __kernel_ulong_t __unused2; ++ __kernel_ulong_t __unused3; ++ __kernel_ulong_t __unused4; ++}; ++ ++#endif ++ ++#endif /* __ASM_X86_SHMBUF_H */ diff --git a/queue-4.16/x86-microcode-do-not-exit-early-from-__reload_late.patch b/queue-4.16/x86-microcode-do-not-exit-early-from-__reload_late.patch new file mode 100644 index 00000000000..e244fb35e46 --- /dev/null +++ b/queue-4.16/x86-microcode-do-not-exit-early-from-__reload_late.patch @@ -0,0 +1,60 @@ +From 09e182d17e8891dd73baba961a0f5a82e9274c97 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Sat, 21 Apr 2018 10:19:30 +0200 +Subject: x86/microcode: Do not exit early from __reload_late() + +From: Borislav Petkov + +commit 09e182d17e8891dd73baba961a0f5a82e9274c97 upstream. + +Vitezslav reported a case where the + + "Timeout during microcode update!" + +panic would hit. After a deeper look, it turned out that his .config had +CONFIG_HOTPLUG_CPU disabled which practically made save_mc_for_early() a +no-op. + +When that happened, the discovered microcode patch wasn't saved into the +cache and the late loading path wouldn't find any. + +This, then, lead to early exit from __reload_late() and thus CPUs waiting +until the timeout is reached, leading to the panic. + +In hindsight, that function should have been written so it does not return +before the post-synchronization. Oh well, I know better now... + +Fixes: bb8c13d61a62 ("x86/microcode: Fix CPU synchronization routine") +Reported-by: Vitezslav Samel +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Tested-by: Vitezslav Samel +Tested-by: Ashok Raj +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/20180418081140.GA2439@pc11.op.pod.cz +Link: https://lkml.kernel.org/r/20180421081930.15741-2-bp@alien8.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/microcode/core.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/arch/x86/kernel/cpu/microcode/core.c ++++ b/arch/x86/kernel/cpu/microcode/core.c +@@ -564,14 +564,12 @@ static int __reload_late(void *info) + apply_microcode_local(&err); + spin_unlock(&update_lock); + ++ /* siblings return UCODE_OK because their engine got updated already */ + if (err > UCODE_NFOUND) { + pr_warn("Error reloading microcode on CPU %d\n", cpu); +- return -1; +- /* siblings return UCODE_OK because their engine got updated already */ ++ ret = -1; + } else if (err == UCODE_UPDATED || err == UCODE_OK) { + ret = 1; +- } else { +- return ret; + } + + /* diff --git a/queue-4.16/x86-microcode-intel-save-microcode-patch-unconditionally.patch b/queue-4.16/x86-microcode-intel-save-microcode-patch-unconditionally.patch new file mode 100644 index 00000000000..e10951aad5f --- /dev/null +++ b/queue-4.16/x86-microcode-intel-save-microcode-patch-unconditionally.patch @@ -0,0 +1,49 @@ +From 84749d83758af6576552046b215b9b7f37f9556b Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Sat, 21 Apr 2018 10:19:29 +0200 +Subject: x86/microcode/intel: Save microcode patch unconditionally + +From: Borislav Petkov + +commit 84749d83758af6576552046b215b9b7f37f9556b upstream. + +save_mc_for_early() was a no-op on !CONFIG_HOTPLUG_CPU but the +generic_load_microcode() path saves the microcode patches it has found into +the cache of patches which is used for late loading too. Regardless of +whether CPU hotplug is used or not. + +Make the saving unconditional so that late loading can find the proper +patch. + +Reported-by: Vitezslav Samel +Signed-off-by: Borislav Petkov +Signed-off-by: Thomas Gleixner +Tested-by: Vitezslav Samel +Tested-by: Ashok Raj +Cc: stable@vger.kernel.org +Link: http://lkml.kernel.org/r/20180418081140.GA2439@pc11.op.pod.cz +Link: https://lkml.kernel.org/r/20180421081930.15741-1-bp@alien8.de +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/microcode/intel.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/arch/x86/kernel/cpu/microcode/intel.c ++++ b/arch/x86/kernel/cpu/microcode/intel.c +@@ -485,7 +485,6 @@ static void show_saved_mc(void) + */ + static void save_mc_for_early(u8 *mc, unsigned int size) + { +-#ifdef CONFIG_HOTPLUG_CPU + /* Synchronization during CPU hotplug. */ + static DEFINE_MUTEX(x86_cpu_microcode_mutex); + +@@ -495,7 +494,6 @@ static void save_mc_for_early(u8 *mc, un + show_saved_mc(); + + mutex_unlock(&x86_cpu_microcode_mutex); +-#endif + } + + static bool load_builtin_intel_microcode(struct cpio_data *cp) diff --git a/queue-4.16/x86-smpboot-don-t-use-mwait_play_dead-on-amd-systems.patch b/queue-4.16/x86-smpboot-don-t-use-mwait_play_dead-on-amd-systems.patch new file mode 100644 index 00000000000..5a6f640f853 --- /dev/null +++ b/queue-4.16/x86-smpboot-don-t-use-mwait_play_dead-on-amd-systems.patch @@ -0,0 +1,44 @@ +From da6fa7ef67f07108a1b0cb9fd9e7fcaabd39c051 Mon Sep 17 00:00:00 2001 +From: Yazen Ghannam +Date: Tue, 3 Apr 2018 09:02:28 -0500 +Subject: x86/smpboot: Don't use mwait_play_dead() on AMD systems + +From: Yazen Ghannam + +commit da6fa7ef67f07108a1b0cb9fd9e7fcaabd39c051 upstream. + +Recent AMD systems support using MWAIT for C1 state. However, MWAIT will +not allow deeper cstates than C1 on current systems. + +play_dead() expects to use the deepest state available. The deepest state +available on AMD systems is reached through SystemIO or HALT. If MWAIT is +available, it is preferred over the other methods, so the CPU never reaches +the deepest possible state. + +Don't try to use MWAIT to play_dead() on AMD systems. Instead, use CPUIDLE +to enter the deepest state advertised by firmware. If CPUIDLE is not +available then fallback to HALT. + +Signed-off-by: Yazen Ghannam +Signed-off-by: Thomas Gleixner +Reviewed-by: Borislav Petkov +Cc: stable@vger.kernel.org +Cc: Yazen Ghannam +Link: https://lkml.kernel.org/r/20180403140228.58540-1-Yazen.Ghannam@amd.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/smpboot.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kernel/smpboot.c ++++ b/arch/x86/kernel/smpboot.c +@@ -1536,6 +1536,8 @@ static inline void mwait_play_dead(void) + void *mwait_ptr; + int i; + ++ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) ++ return; + if (!this_cpu_has(X86_FEATURE_MWAIT)) + return; + if (!this_cpu_has(X86_FEATURE_CLFLUSH))