From: Greg Kroah-Hartman Date: Mon, 1 Apr 2019 10:29:09 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v3.18.138~18 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=55abc57b2fbdfedac0bfc88c3b3bb03ef815f7e9;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: cpu-hotplug-prevent-crash-when-cpu-bringup-fails-on-config_hotplug_cpu-n.patch kvm-reject-device-ioctls-from-processes-other-than-the-vm-s-creator.patch perf-intel-pt-fix-tsc-slip.patch x86-smp-enforce-config_hotplug_cpu-when-smp-y.patch --- diff --git a/queue-4.14/cpu-hotplug-prevent-crash-when-cpu-bringup-fails-on-config_hotplug_cpu-n.patch b/queue-4.14/cpu-hotplug-prevent-crash-when-cpu-bringup-fails-on-config_hotplug_cpu-n.patch new file mode 100644 index 00000000000..79867134536 --- /dev/null +++ b/queue-4.14/cpu-hotplug-prevent-crash-when-cpu-bringup-fails-on-config_hotplug_cpu-n.patch @@ -0,0 +1,142 @@ +From 206b92353c839c0b27a0b9bec24195f93fd6cf7a Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +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 + +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 +Signed-off-by: Thomas Gleixner +Tested-by: Tianyu Lan +Acked-by: Greg Kroah-Hartman +Cc: Konrad Wilk +Cc: Josh Poimboeuf +Cc: Mukesh Ojha +Cc: Peter Zijlstra +Cc: Jiri Kosina +Cc: Rik van Riel +Cc: Andy Lutomirski +Cc: Micheal Kelley +Cc: "K. Y. Srinivasan" +Cc: Linus Torvalds +Cc: Borislav Petkov +Cc: K. Y. Srinivasan +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190326163811.503390616@linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + } diff --git a/queue-4.14/kvm-reject-device-ioctls-from-processes-other-than-the-vm-s-creator.patch b/queue-4.14/kvm-reject-device-ioctls-from-processes-other-than-the-vm-s-creator.patch new file mode 100644 index 00000000000..2835387256b --- /dev/null +++ b/queue-4.14/kvm-reject-device-ioctls-from-processes-other-than-the-vm-s-creator.patch @@ -0,0 +1,78 @@ +From ddba91801aeb5c160b660caed1800eb3aef403f8 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +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 + +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: +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/perf-intel-pt-fix-tsc-slip.patch b/queue-4.14/perf-intel-pt-fix-tsc-slip.patch new file mode 100644 index 00000000000..923ef39d601 --- /dev/null +++ b/queue-4.14/perf-intel-pt-fix-tsc-slip.patch @@ -0,0 +1,56 @@ +From f3b4e06b3bda759afd042d3d5fa86bea8f1fe278 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Mon, 25 Mar 2019 15:51:35 +0200 +Subject: perf intel-pt: Fix TSC slip + +From: Adrian Hunter + +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 +Cc: Jiri Olsa +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/series b/queue-4.14/series index 2219b7d47df..eed16a399c2 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -98,3 +98,7 @@ usb-host-xhci-rcar-add-xhci_trust_tx_length-quirk.patch 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 diff --git a/queue-4.14/x86-smp-enforce-config_hotplug_cpu-when-smp-y.patch b/queue-4.14/x86-smp-enforce-config_hotplug_cpu-when-smp-y.patch new file mode 100644 index 00000000000..9ad8fb8b95b --- /dev/null +++ b/queue-4.14/x86-smp-enforce-config_hotplug_cpu-when-smp-y.patch @@ -0,0 +1,62 @@ +From bebd024e4815b1a170fcd21ead9c2222b23ce9e6 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 26 Mar 2019 17:36:06 +0100 +Subject: x86/smp: Enforce CONFIG_HOTPLUG_CPU when SMP=y + +From: Thomas Gleixner + +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 +Signed-off-by: Thomas Gleixner +Acked-by: Greg Kroah-Hartman +Cc: Konrad Wilk +Cc: Josh Poimboeuf +Cc: Mukesh Ojha +Cc: Peter Zijlstra +Cc: Jiri Kosina +Cc: Rik van Riel +Cc: Andy Lutomirski +Cc: Micheal Kelley +Cc: "K. Y. Srinivasan" +Cc: Linus Torvalds +Cc: Borislav Petkov +Cc: K. Y. Srinivasan +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20190326163811.598166056@linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + 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"