kernel/linux.git/arch/x86, branch linux-4.16.y

x86/intel_rdt: Enable CMT and MBM on new Skylake stepping

2018-06-25T23:54:05+00:00

commit 1d9f3e20a56d33e55748552aeec597f58542f92d upstream. New stepping of Skylake has fixes for cache occupancy and memory bandwidth monitoring. Update the code to enable these by default on newer steppings. Signed-off-by: Tony Luck Signed-off-by: Thomas Gleixner Cc: Fenghua Yu Cc: stable@vger.kernel.org # v4.14 Cc: Vikas Shivappa Link: https://lkml.kernel.org/r/20180608160732.9842-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman

x86/platform/uv: Use apic_ack_irq()

2018-06-25T23:54:04+00:00

commit 839b0f1c4ef674cd929a42304c078afca278581a upstream. To address the EBUSY fail of interrupt affinity settings in case that the previous setting has not been cleaned up yet, use the new apic_ack_irq() function instead of the special uv_ack_apic() implementation which is merily a wrapper around ack_APIC_irq(). Preparatory change for the real fix Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup") Reported-by: Song Liu Signed-off-by: Thomas Gleixner Tested-by: Song Liu Cc: Joerg Roedel Cc: Peter Zijlstra Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: stable@vger.kernel.org Cc: Mike Travis Cc: Borislav Petkov Cc: Tariq Toukan Link: https://lkml.kernel.org/r/20180604162224.721691398@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/ioapic: Use apic_ack_irq()

2018-06-25T23:54:04+00:00

commit 2b04e46d8d0b9b7ac08ded672e3eab823f01d77a upstream. To address the EBUSY fail of interrupt affinity settings in case that the previous setting has not been cleaned up yet, use the new apic_ack_irq() function instead of directly invoking ack_APIC_irq(). Preparatory change for the real fix Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup") Signed-off-by: Thomas Gleixner Tested-by: Song Liu Cc: Joerg Roedel Cc: Peter Zijlstra Cc: Song Liu Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: stable@vger.kernel.org Cc: Mike Travis Cc: Borislav Petkov Cc: Tariq Toukan Link: https://lkml.kernel.org/r/20180604162224.639011135@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/apic: Provide apic_ack_irq()

2018-06-25T23:54:03+00:00

commit c0255770ccdc77ef2184d2a0a2e0cde09d2b44a4 upstream. apic_ack_edge() is explicitely for handling interrupt affinity cleanup when interrupt remapping is not available or disable. Remapped interrupts and also some of the platform specific special interrupts, e.g. UV, invoke ack_APIC_irq() directly. To address the issue of failing an affinity update with -EBUSY the delayed affinity mechanism can be reused, but ack_APIC_irq() does not handle that. Adding this to ack_APIC_irq() is not possible, because that function is also used for exceptions and directly handled interrupts like IPIs. Create a new function, which just contains the conditional invocation of irq_move_irq() and the final ack_APIC_irq(). Reuse the new function in apic_ack_edge(). Preparatory change for the real fix. Fixes: dccfe3147b42 ("x86/vector: Simplify vector move cleanup") Signed-off-by: Thomas Gleixner Tested-by: Song Liu Cc: Joerg Roedel Cc: Peter Zijlstra Cc: Song Liu Cc: Dmitry Safonov <0x7f454c46@gmail.com> Cc: stable@vger.kernel.org Cc: Mike Travis Cc: Borislav Petkov Cc: Tariq Toukan Link: https://lkml.kernel.org/r/20180604162224.471925894@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/apic/vector: Prevent hlist corruption and leaks

2018-06-25T23:54:03+00:00

commit 80ae7b1a918e78b0bae88b0c0ad413d3fdced968 upstream. Several people observed the WARN_ON() in irq_matrix_free() which triggers when the caller tries to free an vector which is not in the allocation range. Song provided the trace information which allowed to decode the root cause. The rework of the vector allocation mechanism failed to preserve a sanity check, which prevents setting a new target vector/CPU when the previous affinity change has not fully completed. As a result a half finished affinity change can be overwritten, which can cause the leak of a irq descriptor pointer on the previous target CPU and double enqueue of the hlist head into the cleanup lists of two or more CPUs. After one CPU cleaned up its vector the next CPU will invoke the cleanup handler with vector 0, which triggers the out of range warning in the matrix allocator. Prevent this by checking the apic_data of the interrupt whether the move_in_progress flag is false and the hlist node is not hashed. Return -EBUSY if not. This prevents the damage and restores the behaviour before the vector allocation rework, but due to other changes in that area it also widens the chance that user space can observe -EBUSY. In theory this should be fine, but actually not all user space tools handle -EBUSY correctly. Addressing that is not part of this fix, but will be addressed in follow up patches. Fixes: 69cde0004a4b ("x86/vector: Use matrix allocator for vector assignment") Reported-by: Dmitry Safonov <0x7f454c46@gmail.com> Reported-by: Tariq Toukan Reported-by: Song Liu Signed-off-by: Thomas Gleixner Tested-by: Song Liu Cc: Joerg Roedel Cc: Peter Zijlstra Cc: stable@vger.kernel.org Cc: Mike Travis Cc: Borislav Petkov Link: https://lkml.kernel.org/r/20180604162224.303870257@linutronix.de Signed-off-by: Greg Kroah-Hartman

x86/vector: Fix the args of vector_alloc tracepoint

2018-06-25T23:54:03+00:00

commit 838d76d63ec4eaeaa12bedfa50f261480f615200 upstream. The vector_alloc tracepont reversed the reserved and ret aggs, that made the trace print wrong. Exchange them. Fixes: 8d1e3dca7de6 ("x86/vector: Add tracepoints for vector management") Signed-off-by: Dou Liyang Signed-off-by: Thomas Gleixner Cc: hpa@zytor.com Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20180601065031.21872-1-douly.fnst@cn.fujitsu.com Signed-off-by: Greg Kroah-Hartman

x86/MCE: Fix stack out-of-bounds write in mce-inject.c: Flags_read()

2018-06-25T23:53:59+00:00

commit 985c78d3ff8e9c74450fa2bb08eb55e680d999ca upstream. Each of the strings that we want to put into the buf[MAX_FLAG_OPT_SIZE] in flags_read() is two characters long. But the sprintf() adds a trailing newline and will add a terminating NUL byte. So MAX_FLAG_OPT_SIZE needs to be 4. sprintf() calls vsnprintf() and *that* does return: " * The return value is the number of characters which would * be generated for the given input, excluding the trailing * '\0', as per ISO C99." Note the "excluding". Reported-by: Dmitry Vyukov Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Cc: linux-edac Link: http://lkml.kernel.org/r/20180427163707.ktaiysvbk3yhk4wm@agluck-desk Signed-off-by: Greg Kroah-Hartman

KVM: X86: Lower the default timer frequency limit to 200us

2018-06-20T19:01:45+00:00

[ Upstream commit 4c27625b7a67eb9006963ed2bcf8e53b259b43af ] Anthoine reported: The period used by Windows change over time but it can be 1 milliseconds or less. I saw the limit_periodic_timer_frequency print so 500 microseconds is sometimes reached. As suggested by Paolo, lower the default timer frequency limit to a smaller interval of 200 us (5000 Hz) to leave some headroom. This is required due to Windows 10 changing the scheduler tick limit from 1024 Hz to 2048 Hz. Reported-by: Anthoine Bourgeois Suggested-by: Paolo Bonzini Reviewed-by: Darren Kenny Cc: Paolo Bonzini Cc: Radim Krčmář Cc: Anthoine Bourgeois Cc: Darren Kenny Cc: Jan Kiszka Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

uprobes/x86: Prohibit probing on MOV SS instruction

2018-06-20T19:01:42+00:00

[ Upstream commit 13ebe18c94f5b0665c01ae7fad2717ae959f4212 ] Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by uprobes must be prohibited. uprobe already rejects probing on POP SS (0x1f), but allows probing on MOV SS (0x8e and reg == 2). This checks the target instruction and if it is MOV SS or POP SS, returns -ENOTSUPP to reject probing. Signed-off-by: Masami Hiramatsu Signed-off-by: Thomas Gleixner Acked-by: Oleg Nesterov Cc: Ricardo Neri Cc: Francis Deslauriers Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Andy Lutomirski Cc: "H . Peter Anvin" Cc: Yonghong Song Cc: Borislav Petkov Cc: Linus Torvalds Cc: "David S . Miller" Link: https://lkml.kernel.org/r/152587072544.17316.5950935243917346341.stgit@devbox Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kprobes/x86: Prohibit probing on exception masking instructions

2018-06-20T19:01:42+00:00

[ Upstream commit ee6a7354a3629f9b65bc18dbe393503e9440d6f5 ] Since MOV SS and POP SS instructions will delay the exceptions until the next instruction is executed, single-stepping on it by kprobes must be prohibited. However, kprobes usually executes those instructions directly on trampoline buffer (a.k.a. kprobe-booster), except for the kprobes which has post_handler. Thus if kprobe user probes MOV SS with post_handler, it will do single-stepping on the MOV SS. This means it is safe that if it is used via ftrace or perf/bpf since those don't use the post_handler. Anyway, since the stack switching is a rare case, it is safer just rejecting kprobes on such instructions. Signed-off-by: Masami Hiramatsu Signed-off-by: Thomas Gleixner Cc: Ricardo Neri Cc: Francis Deslauriers Cc: Oleg Nesterov Cc: Alexei Starovoitov Cc: Steven Rostedt Cc: Andy Lutomirski Cc: "H . Peter Anvin" Cc: Yonghong Song Cc: Borislav Petkov Cc: Linus Torvalds Cc: "David S . Miller" Link: https://lkml.kernel.org/r/152587069574.17316.3311695234863248641.stgit@devbox Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman