--- /dev/null
+From 206b92353c839c0b27a0b9bec24195f93fd6cf7a Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 26 Mar 2019 17:36:05 +0100
+Subject: cpu/hotplug: Prevent crash when CPU bringup fails on CONFIG_HOTPLUG_CPU=n
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 206b92353c839c0b27a0b9bec24195f93fd6cf7a upstream.
+
+Tianyu reported a crash in a CPU hotplug teardown callback when booting a
+kernel which has CONFIG_HOTPLUG_CPU disabled with the 'nosmt' boot
+parameter.
+
+It turns out that the SMP=y CONFIG_HOTPLUG_CPU=n case has been broken
+forever in case that a bringup callback fails. Unfortunately this issue was
+not recognized when the CPU hotplug code was reworked, so the shortcoming
+just stayed in place.
+
+When a bringup callback fails, the CPU hotplug code rolls back the
+operation and takes the CPU offline.
+
+The 'nosmt' command line argument uses a bringup failure to abort the
+bringup of SMT sibling CPUs. This partial bringup is required due to the
+MCE misdesign on Intel CPUs.
+
+With CONFIG_HOTPLUG_CPU=y the rollback works perfectly fine, but
+CONFIG_HOTPLUG_CPU=n lacks essential mechanisms to exercise the low level
+teardown of a CPU including the synchronizations in various facilities like
+RCU, NOHZ and others.
+
+As a consequence the teardown callbacks which must be executed on the
+outgoing CPU within stop machine with interrupts disabled are executed on
+the control CPU in interrupt enabled and preemptible context causing the
+kernel to crash and burn. The pre state machine code has a different
+failure mode which is more subtle and resulting in a less obvious use after
+free crash because the control side frees resources which are still in use
+by the undead CPU.
+
+But this is not a x86 only problem. Any architecture which supports the
+SMP=y HOTPLUG_CPU=n combination suffers from the same issue. It's just less
+likely to be triggered because in 99.99999% of the cases all bringup
+callbacks succeed.
+
+The easy solution of making HOTPLUG_CPU mandatory for SMP is not working on
+all architectures as the following architectures have either no hotplug
+support at all or not all subarchitectures support it:
+
+ alpha, arc, hexagon, openrisc, riscv, sparc (32bit), mips (partial).
+
+Crashing the kernel in such a situation is not an acceptable state
+either.
+
+Implement a minimal rollback variant by limiting the teardown to the point
+where all regular teardown callbacks have been invoked and leave the CPU in
+the 'dead' idle state. This has the following consequences:
+
+ - the CPU is brought down to the point where the stop_machine takedown
+ would happen.
+
+ - the CPU stays there forever and is idle
+
+ - The CPU is cleared in the CPU active mask, but not in the CPU online
+ mask which is a legit state.
+
+ - Interrupts are not forced away from the CPU
+
+ - All facilities which only look at online mask would still see it, but
+ that is the case during normal hotplug/unplug operations as well. It's
+ just a (way) longer time frame.
+
+This will expose issues, which haven't been exposed before or only seldom,
+because now the normally transient state of being non active but online is
+a permanent state. In testing this exposed already an issue vs. work queues
+where the vmstat code schedules work on the almost dead CPU which ends up
+in an unbound workqueue and triggers 'preemtible context' warnings. This is
+not a problem of this change, it merily exposes an already existing issue.
+Still this is better than crashing fully without a chance to debug it.
+
+This is mainly thought as workaround for those architectures which do not
+support HOTPLUG_CPU. All others should enforce HOTPLUG_CPU for SMP.
+
+Fixes: 2e1a3483ce74 ("cpu/hotplug: Split out the state walk into functions")
+Reported-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Konrad Wilk <konrad.wilk@oracle.com>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Mukesh Ojha <mojha@codeaurora.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Jiri Kosina <jkosina@suse.cz>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
+Cc: "K. Y. Srinivasan" <kys@microsoft.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: K. Y. Srinivasan <kys@microsoft.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190326163811.503390616@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/cpu.c | 20 ++++++++++++++++++--
+ 1 file changed, 18 insertions(+), 2 deletions(-)
+
+--- a/kernel/cpu.c
++++ b/kernel/cpu.c
+@@ -538,6 +538,20 @@ static void undo_cpu_up(unsigned int cpu
+ }
+ }
+
++static inline bool can_rollback_cpu(struct cpuhp_cpu_state *st)
++{
++ if (IS_ENABLED(CONFIG_HOTPLUG_CPU))
++ return true;
++ /*
++ * When CPU hotplug is disabled, then taking the CPU down is not
++ * possible because takedown_cpu() and the architecture and
++ * subsystem specific mechanisms are not available. So the CPU
++ * which would be completely unplugged again needs to stay around
++ * in the current state.
++ */
++ return st->state <= CPUHP_BRINGUP_CPU;
++}
++
+ static int cpuhp_up_callbacks(unsigned int cpu, struct cpuhp_cpu_state *st,
+ enum cpuhp_state target)
+ {
+@@ -548,8 +562,10 @@ static int cpuhp_up_callbacks(unsigned i
+ st->state++;
+ ret = cpuhp_invoke_callback(cpu, st->state, true, NULL, NULL);
+ if (ret) {
+- st->target = prev_state;
+- undo_cpu_up(cpu, st);
++ if (can_rollback_cpu(st)) {
++ st->target = prev_state;
++ undo_cpu_up(cpu, st);
++ }
+ break;
+ }
+ }
--- /dev/null
+From ddba91801aeb5c160b660caed1800eb3aef403f8 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+Date: Fri, 15 Feb 2019 12:48:39 -0800
+Subject: KVM: Reject device ioctls from processes other than the VM's creator
+
+From: Sean Christopherson <sean.j.christopherson@intel.com>
+
+commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream.
+
+KVM's API requires thats ioctls must be issued from the same process
+that created the VM. In other words, userspace can play games with a
+VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the
+creator can do anything useful. Explicitly reject device ioctls that
+are issued by a process other than the VM's creator, and update KVM's
+API documentation to extend its requirements to device ioctls.
+
+Fixes: 852b6d57dc7f ("kvm: add device control API")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/virtual/kvm/api.txt | 16 +++++++++++-----
+ virt/kvm/kvm_main.c | 3 +++
+ 2 files changed, 14 insertions(+), 5 deletions(-)
+
+--- a/Documentation/virtual/kvm/api.txt
++++ b/Documentation/virtual/kvm/api.txt
+@@ -13,7 +13,7 @@ of a virtual machine. The ioctls belong
+
+ - VM ioctls: These query and set attributes that affect an entire virtual
+ machine, for example memory layout. In addition a VM ioctl is used to
+- create virtual cpus (vcpus).
++ create virtual cpus (vcpus) and devices.
+
+ Only run VM ioctls from the same process (address space) that was used
+ to create the VM.
+@@ -24,6 +24,11 @@ of a virtual machine. The ioctls belong
+ Only run vcpu ioctls from the same thread that was used to create the
+ vcpu.
+
++ - device ioctls: These query and set attributes that control the operation
++ of a single device.
++
++ device ioctls must be issued from the same process (address space) that
++ was used to create the VM.
+
+ 2. File descriptors
+ -------------------
+@@ -32,10 +37,11 @@ The kvm API is centered around file desc
+ open("/dev/kvm") obtains a handle to the kvm subsystem; this handle
+ can be used to issue system ioctls. A KVM_CREATE_VM ioctl on this
+ handle will create a VM file descriptor which can be used to issue VM
+-ioctls. A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu
+-and return a file descriptor pointing to it. Finally, ioctls on a vcpu
+-fd can be used to control the vcpu, including the important task of
+-actually running guest code.
++ioctls. A KVM_CREATE_VCPU or KVM_CREATE_DEVICE ioctl on a VM fd will
++create a virtual cpu or device and return a file descriptor pointing to
++the new resource. Finally, ioctls on a vcpu or device fd can be used
++to control the vcpu or device. For vcpus, this includes the important
++task of actually running guest code.
+
+ In general file descriptors can be migrated among processes by means
+ of fork() and the SCM_RIGHTS facility of unix domain socket. These
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -2812,6 +2812,9 @@ static long kvm_device_ioctl(struct file
+ {
+ struct kvm_device *dev = filp->private_data;
+
++ if (dev->kvm->mm != current->mm)
++ return -EIO;
++
+ switch (ioctl) {
+ case KVM_SET_DEVICE_ATTR:
+ return kvm_device_ioctl_attr(dev, dev->ops->set_attr, arg);
--- /dev/null
+From f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Mon, 25 Mar 2019 15:51:35 +0200
+Subject: perf intel-pt: Fix TSC slip
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 upstream.
+
+A TSC packet can slip past MTC packets so that the timestamp appears to
+go backwards. One estimate is that can be up to about 40 CPU cycles,
+which is certainly less than 0x1000 TSC ticks, but accept slippage an
+order of magnitude more to be on the safe side.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 79b58424b821c ("perf tools: Add Intel PT support for decoding MTC packets")
+Link: http://lkml.kernel.org/r/20190325135135.18348-1-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 20 ++++++++------------
+ 1 file changed, 8 insertions(+), 12 deletions(-)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -251,19 +251,15 @@ struct intel_pt_decoder *intel_pt_decode
+ if (!(decoder->tsc_ctc_ratio_n % decoder->tsc_ctc_ratio_d))
+ decoder->tsc_ctc_mult = decoder->tsc_ctc_ratio_n /
+ decoder->tsc_ctc_ratio_d;
+-
+- /*
+- * Allow for timestamps appearing to backwards because a TSC
+- * packet has slipped past a MTC packet, so allow 2 MTC ticks
+- * or ...
+- */
+- decoder->tsc_slip = multdiv(2 << decoder->mtc_shift,
+- decoder->tsc_ctc_ratio_n,
+- decoder->tsc_ctc_ratio_d);
+ }
+- /* ... or 0x100 paranoia */
+- if (decoder->tsc_slip < 0x100)
+- decoder->tsc_slip = 0x100;
++
++ /*
++ * A TSC packet can slip past MTC packets so that the timestamp appears
++ * to go backwards. One estimate is that can be up to about 40 CPU
++ * cycles, which is certainly less than 0x1000 TSC ticks, but accept
++ * slippage an order of magnitude more to be on the safe side.
++ */
++ decoder->tsc_slip = 0x10000;
+
+ intel_pt_log("timestamp: mtc_shift %u\n", decoder->mtc_shift);
+ intel_pt_log("timestamp: tsc_ctc_ratio_n %u\n", decoder->tsc_ctc_ratio_n);
xhci-fix-port-resume-done-detection-for-ss-ports-with-lpm-enabled.patch
usb-cdc-acm-fix-race-during-wakeup-blocking-tx-traffic.patch
mm-migrate.c-add-missing-flush_dcache_page-for-non-mapped-page-migrate.patch
+perf-intel-pt-fix-tsc-slip.patch
+cpu-hotplug-prevent-crash-when-cpu-bringup-fails-on-config_hotplug_cpu-n.patch
+x86-smp-enforce-config_hotplug_cpu-when-smp-y.patch
+kvm-reject-device-ioctls-from-processes-other-than-the-vm-s-creator.patch
--- /dev/null
+From bebd024e4815b1a170fcd21ead9c2222b23ce9e6 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 26 Mar 2019 17:36:06 +0100
+Subject: x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit bebd024e4815b1a170fcd21ead9c2222b23ce9e6 upstream.
+
+The SMT disable 'nosmt' command line argument is not working properly when
+CONFIG_HOTPLUG_CPU is disabled. The teardown of the sibling CPUs which are
+required to be brought up due to the MCE issues, cannot work. The CPUs are
+then kept in a half dead state.
+
+As the 'nosmt' functionality has become popular due to the speculative
+hardware vulnerabilities, the half torn down state is not a proper solution
+to the problem.
+
+Enforce CONFIG_HOTPLUG_CPU=y when SMP is enabled so the full operation is
+possible.
+
+Reported-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Konrad Wilk <konrad.wilk@oracle.com>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Mukesh Ojha <mojha@codeaurora.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Jiri Kosina <jkosina@suse.cz>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Andy Lutomirski <luto@kernel.org>
+Cc: Micheal Kelley <michael.h.kelley@microsoft.com>
+Cc: "K. Y. Srinivasan" <kys@microsoft.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: K. Y. Srinivasan <kys@microsoft.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20190326163811.598166056@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/Kconfig | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/arch/x86/Kconfig
++++ b/arch/x86/Kconfig
+@@ -2139,14 +2139,8 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING
+ If unsure, leave at the default value.
+
+ config HOTPLUG_CPU
+- bool "Support for hot-pluggable CPUs"
++ def_bool y
+ depends on SMP
+- ---help---
+- Say Y here to allow turning CPUs off and on. CPUs can be
+- controlled through /sys/devices/system/cpu.
+- ( Note: power management support will enable this option
+- automatically on SMP systems. )
+- Say N if you want to disable CPU hotplug.
+
+ config BOOTPARAM_HOTPLUG_CPU0
+ bool "Set default setting of cpu0_hotpluggable"
projects / thirdparty / kernel / stable-queue.git / commitdiff
