From: Greg Kroah-Hartman Date: Sun, 20 Aug 2017 19:01:11 +0000 (-0700) Subject: 4.12-stable patches X-Git-Tag: v3.18.67~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0f9bea17bb9931771d1bff67145dab0664fcb35d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.12-stable patches added patches: arm-dts-imx6qdl-nitrogen6_som2-fix-pcie-reset.patch blk-mq-pci-add-a-fallback-when-pci_irq_get_affinity-returns-null.patch genirq-ipi-fixup-checks-against-nr_cpu_ids.patch genirq-restore-trigger-settings-in-irq_modify_status.patch irqchip-atmel-aic-fix-unbalanced-of_node_put-in-aic_common_irq_fixup.patch irqchip-atmel-aic-fix-unbalanced-refcount-in-aic_common_rtc_irq_fixup.patch kernel-watchdog-prevent-false-positives-with-turbo-modes.patch mm-cma_debug.c-fix-stack-corruption-due-to-sprintf-usage.patch mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch mm-revert-x86_64-and-arm64-elf_et_dyn_base-base-changes.patch mm-vmalloc.c-don-t-unconditonally-use-__gfp_highmem.patch perf-x86-fix-rdpmc-vs.-mm_struct-tracking.patch powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch x86-asm-64-clear-ac-on-nmi-entries.patch x86-elf-remove-the-unnecessary-addr_no_randomize-checks.patch x86-fix-norandmaps-addr_no_randomize.patch xen-blkfront-use-a-right-index-when-checking-requests.patch xen-fix-bio-vec-merging.patch --- diff --git a/queue-4.12/arm-dts-imx6qdl-nitrogen6_som2-fix-pcie-reset.patch b/queue-4.12/arm-dts-imx6qdl-nitrogen6_som2-fix-pcie-reset.patch new file mode 100644 index 00000000000..5a0a669c59e --- /dev/null +++ b/queue-4.12/arm-dts-imx6qdl-nitrogen6_som2-fix-pcie-reset.patch @@ -0,0 +1,40 @@ +From c40bc54fdf2d52a80f66b365f1eac9d43b32e107 Mon Sep 17 00:00:00 2001 +From: Gary Bisson +Date: Thu, 17 Aug 2017 15:50:10 +0200 +Subject: ARM: dts: imx6qdl-nitrogen6_som2: fix PCIe reset + +From: Gary Bisson + +commit c40bc54fdf2d52a80f66b365f1eac9d43b32e107 upstream. + +Previous value was a bad copy of nitrogen6_max device tree. + +Signed-off-by: Gary Bisson +Fixes: 3faa1bb2e89c ("ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support") +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi ++++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi +@@ -507,7 +507,7 @@ + pinctrl_pcie: pciegrp { + fsl,pins = < + /* PCIe reset */ +- MX6QDL_PAD_EIM_BCLK__GPIO6_IO31 0x030b0 ++ MX6QDL_PAD_EIM_DA0__GPIO3_IO00 0x030b0 + MX6QDL_PAD_EIM_DA4__GPIO3_IO04 0x030b0 + >; + }; +@@ -668,7 +668,7 @@ + &pcie { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pcie>; +- reset-gpio = <&gpio6 31 GPIO_ACTIVE_LOW>; ++ reset-gpio = <&gpio3 0 GPIO_ACTIVE_LOW>; + status = "okay"; + }; + diff --git a/queue-4.12/blk-mq-pci-add-a-fallback-when-pci_irq_get_affinity-returns-null.patch b/queue-4.12/blk-mq-pci-add-a-fallback-when-pci_irq_get_affinity-returns-null.patch new file mode 100644 index 00000000000..3f288e2636d --- /dev/null +++ b/queue-4.12/blk-mq-pci-add-a-fallback-when-pci_irq_get_affinity-returns-null.patch @@ -0,0 +1,45 @@ +From c005390374957baacbc38eef96ea360559510aa7 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Thu, 17 Aug 2017 12:24:47 +0200 +Subject: blk-mq-pci: add a fallback when pci_irq_get_affinity returns NULL + +From: Christoph Hellwig + +commit c005390374957baacbc38eef96ea360559510aa7 upstream. + +While pci_irq_get_affinity should never fail for SMP kernel that +implement the affinity mapping, it will always return NULL in the +UP case, so provide a fallback mapping of all queues to CPU 0 in +that case. + +Signed-off-by: Christoph Hellwig +Reviewed-by: Omar Sandoval +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-mq-pci.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/block/blk-mq-pci.c ++++ b/block/blk-mq-pci.c +@@ -36,12 +36,18 @@ int blk_mq_pci_map_queues(struct blk_mq_ + for (queue = 0; queue < set->nr_hw_queues; queue++) { + mask = pci_irq_get_affinity(pdev, queue); + if (!mask) +- return -EINVAL; ++ goto fallback; + + for_each_cpu(cpu, mask) + set->mq_map[cpu] = queue; + } + + return 0; ++ ++fallback: ++ WARN_ON_ONCE(set->nr_hw_queues > 1); ++ for_each_possible_cpu(cpu) ++ set->mq_map[cpu] = 0; ++ return 0; + } + EXPORT_SYMBOL_GPL(blk_mq_pci_map_queues); diff --git a/queue-4.12/genirq-ipi-fixup-checks-against-nr_cpu_ids.patch b/queue-4.12/genirq-ipi-fixup-checks-against-nr_cpu_ids.patch new file mode 100644 index 00000000000..9586b902d9a --- /dev/null +++ b/queue-4.12/genirq-ipi-fixup-checks-against-nr_cpu_ids.patch @@ -0,0 +1,42 @@ +From 8fbbe2d7cc478d1544f41f2271787c993c23a4f6 Mon Sep 17 00:00:00 2001 +From: Alexey Dobriyan +Date: Sat, 19 Aug 2017 12:57:51 +0300 +Subject: genirq/ipi: Fixup checks against nr_cpu_ids + +From: Alexey Dobriyan + +commit 8fbbe2d7cc478d1544f41f2271787c993c23a4f6 upstream. + +Valid CPU ids are [0, nr_cpu_ids-1] inclusive. + +Fixes: 3b8e29a82dd1 ("genirq: Implement ipi_send_mask/single()") +Fixes: f9bce791ae2a ("genirq: Add a new function to get IPI reverse mapping") +Signed-off-by: Alexey Dobriyan +Signed-off-by: Thomas Gleixner +Link: http://lkml.kernel.org/r/20170819095751.GB27864@avx2 +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/ipi.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/irq/ipi.c ++++ b/kernel/irq/ipi.c +@@ -165,7 +165,7 @@ irq_hw_number_t ipi_get_hwirq(unsigned i + struct irq_data *data = irq_get_irq_data(irq); + struct cpumask *ipimask = data ? irq_data_get_affinity_mask(data) : NULL; + +- if (!data || !ipimask || cpu > nr_cpu_ids) ++ if (!data || !ipimask || cpu >= nr_cpu_ids) + return INVALID_HWIRQ; + + if (!cpumask_test_cpu(cpu, ipimask)) +@@ -195,7 +195,7 @@ static int ipi_send_verify(struct irq_ch + if (!chip->ipi_send_single && !chip->ipi_send_mask) + return -EINVAL; + +- if (cpu > nr_cpu_ids) ++ if (cpu >= nr_cpu_ids) + return -EINVAL; + + if (dest) { diff --git a/queue-4.12/genirq-restore-trigger-settings-in-irq_modify_status.patch b/queue-4.12/genirq-restore-trigger-settings-in-irq_modify_status.patch new file mode 100644 index 00000000000..9398daf4569 --- /dev/null +++ b/queue-4.12/genirq-restore-trigger-settings-in-irq_modify_status.patch @@ -0,0 +1,61 @@ +From e8f241893dfbbebe2813c01eac54f263e6a5e59c Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Fri, 18 Aug 2017 10:53:45 +0100 +Subject: genirq: Restore trigger settings in irq_modify_status() + +From: Marc Zyngier + +commit e8f241893dfbbebe2813c01eac54f263e6a5e59c upstream. + +irq_modify_status starts by clearing the trigger settings from +irq_data before applying the new settings, but doesn't restore them, +leaving them to IRQ_TYPE_NONE. + +That's pretty confusing to the potential request_irq() that could +follow. Instead, snapshot the settings before clearing them, and restore +them if the irq_modify_status() invocation was not changing the trigger. + +Fixes: 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ") +Reported-and-tested-by: jeffy +Signed-off-by: Marc Zyngier +Signed-off-by: Thomas Gleixner +Cc: Jon Hunter +Link: http://lkml.kernel.org/r/20170818095345.12378-1-marc.zyngier@arm.com +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/irq/chip.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +--- a/kernel/irq/chip.c ++++ b/kernel/irq/chip.c +@@ -898,13 +898,15 @@ EXPORT_SYMBOL_GPL(irq_set_chip_and_handl + + void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set) + { +- unsigned long flags; ++ unsigned long flags, trigger, tmp; + struct irq_desc *desc = irq_get_desc_lock(irq, &flags, 0); + + if (!desc) + return; + irq_settings_clr_and_set(desc, clr, set); + ++ trigger = irqd_get_trigger_type(&desc->irq_data); ++ + irqd_clear(&desc->irq_data, IRQD_NO_BALANCING | IRQD_PER_CPU | + IRQD_TRIGGER_MASK | IRQD_LEVEL | IRQD_MOVE_PCNTXT); + if (irq_settings_has_no_balance_set(desc)) +@@ -916,7 +918,11 @@ void irq_modify_status(unsigned int irq, + if (irq_settings_is_level(desc)) + irqd_set(&desc->irq_data, IRQD_LEVEL); + +- irqd_set(&desc->irq_data, irq_settings_get_trigger_mask(desc)); ++ tmp = irq_settings_get_trigger_mask(desc); ++ if (tmp != IRQ_TYPE_NONE) ++ trigger = tmp; ++ ++ irqd_set(&desc->irq_data, trigger); + + irq_put_desc_unlock(desc, flags); + } diff --git a/queue-4.12/irqchip-atmel-aic-fix-unbalanced-of_node_put-in-aic_common_irq_fixup.patch b/queue-4.12/irqchip-atmel-aic-fix-unbalanced-of_node_put-in-aic_common_irq_fixup.patch new file mode 100644 index 00000000000..bcd8dc9add2 --- /dev/null +++ b/queue-4.12/irqchip-atmel-aic-fix-unbalanced-of_node_put-in-aic_common_irq_fixup.patch @@ -0,0 +1,32 @@ +From 469bcef53c546bb792aa66303933272991b7831d Mon Sep 17 00:00:00 2001 +From: Boris Brezillon +Date: Tue, 4 Jul 2017 11:10:39 +0200 +Subject: irqchip/atmel-aic: Fix unbalanced of_node_put() in aic_common_irq_fixup() + +From: Boris Brezillon + +commit 469bcef53c546bb792aa66303933272991b7831d upstream. + +aic_common_irq_fixup() is calling twice of_node_put() on the same node +thus leading to an unbalanced refcount on the root node. + +Signed-off-by: Boris Brezillon +Reported-by: Alexandre Belloni +Fixes: b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure") +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-atmel-aic-common.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/irqchip/irq-atmel-aic-common.c ++++ b/drivers/irqchip/irq-atmel-aic-common.c +@@ -196,7 +196,6 @@ static void __init aic_common_irq_fixup( + return; + + match = of_match_node(matches, root); +- of_node_put(root); + + if (match) { + void (*fixup)(struct device_node *) = match->data; diff --git a/queue-4.12/irqchip-atmel-aic-fix-unbalanced-refcount-in-aic_common_rtc_irq_fixup.patch b/queue-4.12/irqchip-atmel-aic-fix-unbalanced-refcount-in-aic_common_rtc_irq_fixup.patch new file mode 100644 index 00000000000..1b661e106f9 --- /dev/null +++ b/queue-4.12/irqchip-atmel-aic-fix-unbalanced-refcount-in-aic_common_rtc_irq_fixup.patch @@ -0,0 +1,40 @@ +From 277867ade8262583f4280cadbe90e0031a3706a7 Mon Sep 17 00:00:00 2001 +From: Boris Brezillon +Date: Tue, 4 Jul 2017 11:10:40 +0200 +Subject: irqchip/atmel-aic: Fix unbalanced refcount in aic_common_rtc_irq_fixup() + +From: Boris Brezillon + +commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream. + +of_find_compatible_node() is calling of_node_put() on its first argument +thus leading to an unbalanced of_node_get/put() issue if the node has not +been retained before that. + +Instead of passing the root node, pass NULL, which does exactly the same: +iterate over all DT nodes, starting from the root node. + +Signed-off-by: Boris Brezillon +Reported-by: Alexandre Belloni +Fixes: 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup") +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/irqchip/irq-atmel-aic-common.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/irqchip/irq-atmel-aic-common.c ++++ b/drivers/irqchip/irq-atmel-aic-common.c +@@ -142,9 +142,9 @@ void __init aic_common_rtc_irq_fixup(str + struct device_node *np; + void __iomem *regs; + +- np = of_find_compatible_node(root, NULL, "atmel,at91rm9200-rtc"); ++ np = of_find_compatible_node(NULL, NULL, "atmel,at91rm9200-rtc"); + if (!np) +- np = of_find_compatible_node(root, NULL, ++ np = of_find_compatible_node(NULL, NULL, + "atmel,at91sam9x5-rtc"); + + if (!np) diff --git a/queue-4.12/kernel-watchdog-prevent-false-positives-with-turbo-modes.patch b/queue-4.12/kernel-watchdog-prevent-false-positives-with-turbo-modes.patch new file mode 100644 index 00000000000..2f13d7d53aa --- /dev/null +++ b/queue-4.12/kernel-watchdog-prevent-false-positives-with-turbo-modes.patch @@ -0,0 +1,184 @@ +From 7edaeb6841dfb27e362288ab8466ebdc4972e867 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Tue, 15 Aug 2017 09:50:13 +0200 +Subject: kernel/watchdog: Prevent false positives with turbo modes + +From: Thomas Gleixner + +commit 7edaeb6841dfb27e362288ab8466ebdc4972e867 upstream. + +The hardlockup detector on x86 uses a performance counter based on unhalted +CPU cycles and a periodic hrtimer. The hrtimer period is about 2/5 of the +performance counter period, so the hrtimer should fire 2-3 times before the +performance counter NMI fires. The NMI code checks whether the hrtimer +fired since the last invocation. If not, it assumess a hard lockup. + +The calculation of those periods is based on the nominal CPU +frequency. Turbo modes increase the CPU clock frequency and therefore +shorten the period of the perf/NMI watchdog. With extreme Turbo-modes (3x +nominal frequency) the perf/NMI period is shorter than the hrtimer period +which leads to false positives. + +A simple fix would be to shorten the hrtimer period, but that comes with +the side effect of more frequent hrtimer and softlockup thread wakeups, +which is not desired. + +Implement a low pass filter, which checks the perf/NMI period against +kernel time. If the perf/NMI fires before 4/5 of the watchdog period has +elapsed then the event is ignored and postponed to the next perf/NMI. + +That solves the problem and avoids the overhead of shorter hrtimer periods +and more frequent softlockup thread wakeups. + +Fixes: 58687acba592 ("lockup_detector: Combine nmi_watchdog and softlockup detector") +Reported-and-tested-by: Kan Liang +Signed-off-by: Thomas Gleixner +Cc: dzickus@redhat.com +Cc: prarit@redhat.com +Cc: ak@linux.intel.com +Cc: babu.moger@oracle.com +Cc: peterz@infradead.org +Cc: eranian@google.com +Cc: acme@redhat.com +Cc: atomlin@redhat.com +Cc: akpm@linux-foundation.org +Cc: torvalds@linux-foundation.org +Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1708150931310.1886@nanos +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/Kconfig | 1 + include/linux/nmi.h | 8 ++++++ + kernel/watchdog.c | 1 + kernel/watchdog_hld.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++++ + lib/Kconfig.debug | 7 +++++ + 5 files changed, 76 insertions(+) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -94,6 +94,7 @@ config X86 + select GENERIC_STRNCPY_FROM_USER + select GENERIC_STRNLEN_USER + select GENERIC_TIME_VSYSCALL ++ select HARDLOCKUP_CHECK_TIMESTAMP if X86_64 + select HAVE_ACPI_APEI if ACPI + select HAVE_ACPI_APEI_NMI if ACPI + select HAVE_ALIGNED_STRUCT_PAGE if SLUB +--- a/include/linux/nmi.h ++++ b/include/linux/nmi.h +@@ -155,6 +155,14 @@ extern int sysctl_hardlockup_all_cpu_bac + #define sysctl_softlockup_all_cpu_backtrace 0 + #define sysctl_hardlockup_all_cpu_backtrace 0 + #endif ++ ++#if defined(CONFIG_HARDLOCKUP_CHECK_TIMESTAMP) && \ ++ defined(CONFIG_HARDLOCKUP_DETECTOR) ++void watchdog_update_hrtimer_threshold(u64 period); ++#else ++static inline void watchdog_update_hrtimer_threshold(u64 period) { } ++#endif ++ + extern bool is_hardlockup(void); + struct ctl_table; + extern int proc_watchdog(struct ctl_table *, int , +--- a/kernel/watchdog.c ++++ b/kernel/watchdog.c +@@ -161,6 +161,7 @@ static void set_sample_period(void) + * hardlockup detector generates a warning + */ + sample_period = get_softlockup_thresh() * ((u64)NSEC_PER_SEC / 5); ++ watchdog_update_hrtimer_threshold(sample_period); + } + + /* Commands for resetting the watchdog */ +--- a/kernel/watchdog_hld.c ++++ b/kernel/watchdog_hld.c +@@ -70,6 +70,62 @@ void touch_nmi_watchdog(void) + } + EXPORT_SYMBOL(touch_nmi_watchdog); + ++#ifdef CONFIG_HARDLOCKUP_CHECK_TIMESTAMP ++static DEFINE_PER_CPU(ktime_t, last_timestamp); ++static DEFINE_PER_CPU(unsigned int, nmi_rearmed); ++static ktime_t watchdog_hrtimer_sample_threshold __read_mostly; ++ ++void watchdog_update_hrtimer_threshold(u64 period) ++{ ++ /* ++ * The hrtimer runs with a period of (watchdog_threshold * 2) / 5 ++ * ++ * So it runs effectively with 2.5 times the rate of the NMI ++ * watchdog. That means the hrtimer should fire 2-3 times before ++ * the NMI watchdog expires. The NMI watchdog on x86 is based on ++ * unhalted CPU cycles, so if Turbo-Mode is enabled the CPU cycles ++ * might run way faster than expected and the NMI fires in a ++ * smaller period than the one deduced from the nominal CPU ++ * frequency. Depending on the Turbo-Mode factor this might be fast ++ * enough to get the NMI period smaller than the hrtimer watchdog ++ * period and trigger false positives. ++ * ++ * The sample threshold is used to check in the NMI handler whether ++ * the minimum time between two NMI samples has elapsed. That ++ * prevents false positives. ++ * ++ * Set this to 4/5 of the actual watchdog threshold period so the ++ * hrtimer is guaranteed to fire at least once within the real ++ * watchdog threshold. ++ */ ++ watchdog_hrtimer_sample_threshold = period * 2; ++} ++ ++static bool watchdog_check_timestamp(void) ++{ ++ ktime_t delta, now = ktime_get_mono_fast_ns(); ++ ++ delta = now - __this_cpu_read(last_timestamp); ++ if (delta < watchdog_hrtimer_sample_threshold) { ++ /* ++ * If ktime is jiffies based, a stalled timer would prevent ++ * jiffies from being incremented and the filter would look ++ * at a stale timestamp and never trigger. ++ */ ++ if (__this_cpu_inc_return(nmi_rearmed) < 10) ++ return false; ++ } ++ __this_cpu_write(nmi_rearmed, 0); ++ __this_cpu_write(last_timestamp, now); ++ return true; ++} ++#else ++static inline bool watchdog_check_timestamp(void) ++{ ++ return true; ++} ++#endif ++ + static struct perf_event_attr wd_hw_attr = { + .type = PERF_TYPE_HARDWARE, + .config = PERF_COUNT_HW_CPU_CYCLES, +@@ -94,6 +150,9 @@ static void watchdog_overflow_callback(s + return; + } + ++ if (!watchdog_check_timestamp()) ++ return; ++ + /* check for a hardlockup + * This is done by making sure our timer interrupt + * is incrementing. The timer interrupt should have +--- a/lib/Kconfig.debug ++++ b/lib/Kconfig.debug +@@ -345,6 +345,13 @@ config SECTION_MISMATCH_WARN_ONLY + If unsure, say Y. + + # ++# Enables a timestamp based low pass filter to compensate for perf based ++# hard lockup detection which runs too fast due to turbo modes. ++# ++config HARDLOCKUP_CHECK_TIMESTAMP ++ bool ++ ++# + # Select this config option from the architecture Kconfig, if it + # is preferred to always offer frame pointers as a config + # option on the architecture (regardless of KERNEL_DEBUG): diff --git a/queue-4.12/mm-cma_debug.c-fix-stack-corruption-due-to-sprintf-usage.patch b/queue-4.12/mm-cma_debug.c-fix-stack-corruption-due-to-sprintf-usage.patch new file mode 100644 index 00000000000..d6213f57e25 --- /dev/null +++ b/queue-4.12/mm-cma_debug.c-fix-stack-corruption-due-to-sprintf-usage.patch @@ -0,0 +1,56 @@ +From da094e42848e3c36feaa3b5271e53983fd45424f Mon Sep 17 00:00:00 2001 +From: Prakash Gupta +Date: Fri, 18 Aug 2017 15:16:21 -0700 +Subject: mm/cma_debug.c: fix stack corruption due to sprintf usage + +From: Prakash Gupta + +commit da094e42848e3c36feaa3b5271e53983fd45424f upstream. + +name[] in cma_debugfs_add_one() can only accommodate 16 chars including +NULL to store sprintf output. It's common for cma device name to be +larger than 15 chars. This can cause stack corrpution. If the gcc +stack protector is turned on, this can cause a panic due to stack +corruption. + +Below is one example trace: + + Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: + ffffff8e69a75730 + Call trace: + dump_backtrace+0x0/0x2c4 + show_stack+0x20/0x28 + dump_stack+0xb8/0xf4 + panic+0x154/0x2b0 + print_tainted+0x0/0xc0 + cma_debugfs_init+0x274/0x290 + do_one_initcall+0x5c/0x168 + kernel_init_freeable+0x1c8/0x280 + +Fix the short sprintf buffer in cma_debugfs_add_one() by using +scnprintf() instead of sprintf(). + +Link: http://lkml.kernel.org/r/1502446217-21840-1-git-send-email-guptap@codeaurora.org +Fixes: f318dd083c81 ("cma: Store a name in the cma structure") +Signed-off-by: Prakash Gupta +Acked-by: Laura Abbott +Cc: Greg Kroah-Hartman +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/cma_debug.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/cma_debug.c ++++ b/mm/cma_debug.c +@@ -167,7 +167,7 @@ static void cma_debugfs_add_one(struct c + char name[16]; + int u32s; + +- sprintf(name, "cma-%s", cma->name); ++ scnprintf(name, sizeof(name), "cma-%s", cma->name); + + tmp = debugfs_create_dir(name, cma_debugfs_root); + diff --git a/queue-4.12/mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch b/queue-4.12/mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch new file mode 100644 index 00000000000..d9ad4c04d91 --- /dev/null +++ b/queue-4.12/mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch @@ -0,0 +1,76 @@ +From 5b53a6ea886700a128b697a6fe8375340dea2c30 Mon Sep 17 00:00:00 2001 +From: Michal Hocko +Date: Fri, 18 Aug 2017 15:16:12 -0700 +Subject: mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS + +From: Michal Hocko + +commit 5b53a6ea886700a128b697a6fe8375340dea2c30 upstream. + +Tetsuo Handa has noticed that MMF_UNSTABLE SIGBUS path in +handle_mm_fault causes a lockdep splat + + Out of memory: Kill process 1056 (a.out) score 603 or sacrifice child + Killed process 1056 (a.out) total-vm:4268108kB, anon-rss:2246048kB, file-rss:0kB, shmem-rss:0kB + a.out (1169) used greatest stack depth: 11664 bytes left + DEBUG_LOCKS_WARN_ON(depth <= 0) + ------------[ cut here ]------------ + WARNING: CPU: 6 PID: 1339 at kernel/locking/lockdep.c:3617 lock_release+0x172/0x1e0 + CPU: 6 PID: 1339 Comm: a.out Not tainted 4.13.0-rc3-next-20170803+ #142 + Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015 + RIP: 0010:lock_release+0x172/0x1e0 + Call Trace: + up_read+0x1a/0x40 + __do_page_fault+0x28e/0x4c0 + do_page_fault+0x30/0x80 + page_fault+0x28/0x30 + +The reason is that the page fault path might have dropped the mmap_sem +and returned with VM_FAULT_RETRY. MMF_UNSTABLE check however rewrites +the error path to VM_FAULT_SIGBUS and we always expect mmap_sem taken in +that path. Fix this by taking mmap_sem when VM_FAULT_RETRY is held in +the MMF_UNSTABLE path. + +We cannot simply add VM_FAULT_SIGBUS to the existing error code because +all arch specific page fault handlers and g-u-p would have to learn a +new error code combination. + +Link: http://lkml.kernel.org/r/20170807113839.16695-2-mhocko@kernel.org +Fixes: 3f70dc38cec2 ("mm: make sure that kthreads will not refault oom reaped memory") +Reported-by: Tetsuo Handa +Signed-off-by: Michal Hocko +Acked-by: David Rientjes +Cc: Andrea Argangeli +Cc: "Kirill A. Shutemov" +Cc: Oleg Nesterov +Cc: Wenwei Tao +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -3882,8 +3882,18 @@ int handle_mm_fault(struct vm_area_struc + * further. + */ + if (unlikely((current->flags & PF_KTHREAD) && !(ret & VM_FAULT_ERROR) +- && test_bit(MMF_UNSTABLE, &vma->vm_mm->flags))) ++ && test_bit(MMF_UNSTABLE, &vma->vm_mm->flags))) { ++ ++ /* ++ * We are going to enforce SIGBUS but the PF path might have ++ * dropped the mmap_sem already so take it again so that ++ * we do not break expectations of all arch specific PF paths ++ * and g-u-p ++ */ ++ if (ret & VM_FAULT_RETRY) ++ down_read(&vma->vm_mm->mmap_sem); + ret = VM_FAULT_SIGBUS; ++ } + + return ret; + } diff --git a/queue-4.12/mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch b/queue-4.12/mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch new file mode 100644 index 00000000000..023b6ebcda4 --- /dev/null +++ b/queue-4.12/mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch @@ -0,0 +1,83 @@ +From 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 Mon Sep 17 00:00:00 2001 +From: zhong jiang +Date: Fri, 18 Aug 2017 15:16:24 -0700 +Subject: mm/mempolicy: fix use after free when calling get_mempolicy + +From: zhong jiang + +commit 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 upstream. + +I hit a use after free issue when executing trinity and repoduced it +with KASAN enabled. The related call trace is as follows. + + BUG: KASan: use after free in SyS_get_mempolicy+0x3c8/0x960 at addr ffff8801f582d766 + Read of size 2 by task syz-executor1/798 + + INFO: Allocated in mpol_new.part.2+0x74/0x160 age=3 cpu=1 pid=799 + __slab_alloc+0x768/0x970 + kmem_cache_alloc+0x2e7/0x450 + mpol_new.part.2+0x74/0x160 + mpol_new+0x66/0x80 + SyS_mbind+0x267/0x9f0 + system_call_fastpath+0x16/0x1b + INFO: Freed in __mpol_put+0x2b/0x40 age=4 cpu=1 pid=799 + __slab_free+0x495/0x8e0 + kmem_cache_free+0x2f3/0x4c0 + __mpol_put+0x2b/0x40 + SyS_mbind+0x383/0x9f0 + system_call_fastpath+0x16/0x1b + INFO: Slab 0xffffea0009cb8dc0 objects=23 used=8 fp=0xffff8801f582de40 flags=0x200000000004080 + INFO: Object 0xffff8801f582d760 @offset=5984 fp=0xffff8801f582d600 + + Bytes b4 ffff8801f582d750: ae 01 ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ + Object ffff8801f582d760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk + Object ffff8801f582d770: 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkk. + Redzone ffff8801f582d778: bb bb bb bb bb bb bb bb ........ + Padding ffff8801f582d8b8: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ + Memory state around the buggy address: + ffff8801f582d600: fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff8801f582d680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + >ffff8801f582d700: fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb fc + +!shared memory policy is not protected against parallel removal by other +thread which is normally protected by the mmap_sem. do_get_mempolicy, +however, drops the lock midway while we can still access it later. + +Early premature up_read is a historical artifact from times when +put_user was called in this path see https://lwn.net/Articles/124754/ +but that is gone since 8bccd85ffbaf ("[PATCH] Implement sys_* do_* +layering in the memory policy layer."). but when we have the the +current mempolicy ref count model. The issue was introduced +accordingly. + +Fix the issue by removing the premature release. + +Link: http://lkml.kernel.org/r/1502950924-27521-1-git-send-email-zhongjiang@huawei.com +Signed-off-by: zhong jiang +Acked-by: Michal Hocko +Cc: Minchan Kim +Cc: Vlastimil Babka +Cc: David Rientjes +Cc: Mel Gorman +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/mempolicy.c | 5 ----- + 1 file changed, 5 deletions(-) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -931,11 +931,6 @@ static long do_get_mempolicy(int *policy + *policy |= (pol->flags & MPOL_MODE_FLAGS); + } + +- if (vma) { +- up_read(¤t->mm->mmap_sem); +- vma = NULL; +- } +- + err = 0; + if (nmask) { + if (mpol_store_user_nodemask(pol)) { diff --git a/queue-4.12/mm-revert-x86_64-and-arm64-elf_et_dyn_base-base-changes.patch b/queue-4.12/mm-revert-x86_64-and-arm64-elf_et_dyn_base-base-changes.patch new file mode 100644 index 00000000000..0e2caaec6e6 --- /dev/null +++ b/queue-4.12/mm-revert-x86_64-and-arm64-elf_et_dyn_base-base-changes.patch @@ -0,0 +1,82 @@ +From c715b72c1ba406f133217b509044c38d8e714a37 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Fri, 18 Aug 2017 15:16:31 -0700 +Subject: mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes + +From: Kees Cook + +commit c715b72c1ba406f133217b509044c38d8e714a37 upstream. + +Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000 +broke AddressSanitizer. This is a partial revert of: + + eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") + 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB") + +The AddressSanitizer tool has hard-coded expectations about where +executable mappings are loaded. + +The motivation for changing the PIE base in the above commits was to +avoid the Stack-Clash CVEs that allowed executable mappings to get too +close to heap and stack. This was mainly a problem on 32-bit, but the +64-bit bases were moved too, in an effort to proactively protect those +systems (proofs of concept do exist that show 64-bit collisions, but +other recent changes to fix stack accounting and setuid behaviors will +minimize the impact). + +The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC +base), so only the 64-bit PIE base needs to be reverted to let x86 and +arm64 ASan binaries run again. Future changes to the 64-bit PIE base on +these architectures can be made optional once a more dynamic method for +dealing with AddressSanitizer is found. (e.g. always loading PIE into +the mmap region for marked binaries.) + +Link: http://lkml.kernel.org/r/20170807201542.GA21271@beast +Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE") +Fixes: 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB") +Signed-off-by: Kees Cook +Reported-by: Kostya Serebryany +Acked-by: Will Deacon +Cc: Ingo Molnar +Cc: "H. Peter Anvin" +Cc: Thomas Gleixner +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/elf.h | 4 ++-- + arch/x86/include/asm/elf.h | 4 ++-- + 2 files changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/arm64/include/asm/elf.h ++++ b/arch/arm64/include/asm/elf.h +@@ -114,10 +114,10 @@ + + /* + * This is the base location for PIE (ET_DYN with INTERP) loads. On +- * 64-bit, this is raised to 4GB to leave the entire 32-bit address ++ * 64-bit, this is above 4GB to leave the entire 32-bit address + * space open for things that want to use the area for 32-bit pointers. + */ +-#define ELF_ET_DYN_BASE 0x100000000UL ++#define ELF_ET_DYN_BASE (2 * TASK_SIZE_64 / 3) + + #ifndef __ASSEMBLY__ + +--- a/arch/x86/include/asm/elf.h ++++ b/arch/x86/include/asm/elf.h +@@ -247,11 +247,11 @@ extern int force_personality32; + + /* + * This is the base location for PIE (ET_DYN with INTERP) loads. On +- * 64-bit, this is raised to 4GB to leave the entire 32-bit address ++ * 64-bit, this is above 4GB to leave the entire 32-bit address + * space open for things that want to use the area for 32-bit pointers. + */ + #define ELF_ET_DYN_BASE (mmap_is_ia32() ? 0x000400000UL : \ +- 0x100000000UL) ++ (TASK_SIZE / 3 * 2)) + + /* This yields a mask that user programs can use to figure out what + instruction set this CPU supports. This could be done in user space, diff --git a/queue-4.12/mm-vmalloc.c-don-t-unconditonally-use-__gfp_highmem.patch b/queue-4.12/mm-vmalloc.c-don-t-unconditonally-use-__gfp_highmem.patch new file mode 100644 index 00000000000..d93f7e5d95d --- /dev/null +++ b/queue-4.12/mm-vmalloc.c-don-t-unconditonally-use-__gfp_highmem.patch @@ -0,0 +1,75 @@ +From 704b862f9efd6d4c87a8d0a344dda19bda9c6b69 Mon Sep 17 00:00:00 2001 +From: Laura Abbott +Date: Fri, 18 Aug 2017 15:16:27 -0700 +Subject: mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM + +From: Laura Abbott + +commit 704b862f9efd6d4c87a8d0a344dda19bda9c6b69 upstream. + +Commit 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly") added +use of __GFP_HIGHMEM for allocations. vmalloc_32 may use +GFP_DMA/GFP_DMA32 which does not play nice with __GFP_HIGHMEM and will +trigger a BUG in gfp_zone. + +Only add __GFP_HIGHMEM if we aren't using GFP_DMA/GFP_DMA32. + +Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1482249 +Link: http://lkml.kernel.org/r/20170816220705.31374-1-labbott@redhat.com +Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly") +Signed-off-by: Laura Abbott +Acked-by: Michal Hocko +Cc: Vlastimil Babka +Cc: "Kirill A. Shutemov" +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmalloc.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/mm/vmalloc.c ++++ b/mm/vmalloc.c +@@ -1669,7 +1669,10 @@ static void *__vmalloc_area_node(struct + struct page **pages; + unsigned int nr_pages, array_size, i; + const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO; +- const gfp_t alloc_mask = gfp_mask | __GFP_HIGHMEM | __GFP_NOWARN; ++ const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN; ++ const gfp_t highmem_mask = (gfp_mask & (GFP_DMA | GFP_DMA32)) ? ++ 0 : ++ __GFP_HIGHMEM; + + nr_pages = get_vm_area_size(area) >> PAGE_SHIFT; + array_size = (nr_pages * sizeof(struct page *)); +@@ -1677,7 +1680,7 @@ static void *__vmalloc_area_node(struct + area->nr_pages = nr_pages; + /* Please note that the recursion is strictly bounded. */ + if (array_size > PAGE_SIZE) { +- pages = __vmalloc_node(array_size, 1, nested_gfp|__GFP_HIGHMEM, ++ pages = __vmalloc_node(array_size, 1, nested_gfp|highmem_mask, + PAGE_KERNEL, node, area->caller); + } else { + pages = kmalloc_node(array_size, nested_gfp, node); +@@ -1698,9 +1701,9 @@ static void *__vmalloc_area_node(struct + } + + if (node == NUMA_NO_NODE) +- page = alloc_page(alloc_mask); ++ page = alloc_page(alloc_mask|highmem_mask); + else +- page = alloc_pages_node(node, alloc_mask, 0); ++ page = alloc_pages_node(node, alloc_mask|highmem_mask, 0); + + if (unlikely(!page)) { + /* Successfully allocated i pages, free them in __vunmap() */ +@@ -1708,7 +1711,7 @@ static void *__vmalloc_area_node(struct + goto fail; + } + area->pages[i] = page; +- if (gfpflags_allow_blocking(gfp_mask)) ++ if (gfpflags_allow_blocking(gfp_mask|highmem_mask)) + cond_resched(); + } + diff --git a/queue-4.12/perf-x86-fix-rdpmc-vs.-mm_struct-tracking.patch b/queue-4.12/perf-x86-fix-rdpmc-vs.-mm_struct-tracking.patch new file mode 100644 index 00000000000..d359c390f08 --- /dev/null +++ b/queue-4.12/perf-x86-fix-rdpmc-vs.-mm_struct-tracking.patch @@ -0,0 +1,130 @@ +From bfe334924ccd9f4a53f30240c03cf2f43f5b2df1 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Wed, 2 Aug 2017 19:39:30 +0200 +Subject: perf/x86: Fix RDPMC vs. mm_struct tracking + +From: Peter Zijlstra + +commit bfe334924ccd9f4a53f30240c03cf2f43f5b2df1 upstream. + +Vince reported the following rdpmc() testcase failure: + + > Failing test case: + > + > fd=perf_event_open(); + > addr=mmap(fd); + > exec() // without closing or unmapping the event + > fd=perf_event_open(); + > addr=mmap(fd); + > rdpmc() // GPFs due to rdpmc being disabled + +The problem is of course that exec() plays tricks with what is +current->mm, only destroying the old mappings after having +installed the new mm. + +Fix this confusion by passing along vma->vm_mm instead of relying on +current->mm. + +Reported-by: Vince Weaver +Tested-by: Vince Weaver +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Andy Lutomirski +Cc: Arnaldo Carvalho de Melo +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Fixes: 1e0fb9ec679c ("perf: Add pmu callbacks to track event mapping and unmapping") +Link: http://lkml.kernel.org/r/20170802173930.cstykcqefmqt7jau@hirez.programming.kicks-ass.net +[ Minor cleanups. ] +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/core.c | 16 +++++++--------- + include/linux/perf_event.h | 4 ++-- + kernel/events/core.c | 6 +++--- + 3 files changed, 12 insertions(+), 14 deletions(-) + +--- a/arch/x86/events/core.c ++++ b/arch/x86/events/core.c +@@ -2105,7 +2105,7 @@ static void refresh_pce(void *ignored) + load_mm_cr4(current->active_mm); + } + +-static void x86_pmu_event_mapped(struct perf_event *event) ++static void x86_pmu_event_mapped(struct perf_event *event, struct mm_struct *mm) + { + if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED)) + return; +@@ -2120,22 +2120,20 @@ static void x86_pmu_event_mapped(struct + * For now, this can't happen because all callers hold mmap_sem + * for write. If this changes, we'll need a different solution. + */ +- lockdep_assert_held_exclusive(¤t->mm->mmap_sem); ++ lockdep_assert_held_exclusive(&mm->mmap_sem); + +- if (atomic_inc_return(¤t->mm->context.perf_rdpmc_allowed) == 1) +- on_each_cpu_mask(mm_cpumask(current->mm), refresh_pce, NULL, 1); ++ if (atomic_inc_return(&mm->context.perf_rdpmc_allowed) == 1) ++ on_each_cpu_mask(mm_cpumask(mm), refresh_pce, NULL, 1); + } + +-static void x86_pmu_event_unmapped(struct perf_event *event) ++static void x86_pmu_event_unmapped(struct perf_event *event, struct mm_struct *mm) + { +- if (!current->mm) +- return; + + if (!(event->hw.flags & PERF_X86_EVENT_RDPMC_ALLOWED)) + return; + +- if (atomic_dec_and_test(¤t->mm->context.perf_rdpmc_allowed)) +- on_each_cpu_mask(mm_cpumask(current->mm), refresh_pce, NULL, 1); ++ if (atomic_dec_and_test(&mm->context.perf_rdpmc_allowed)) ++ on_each_cpu_mask(mm_cpumask(mm), refresh_pce, NULL, 1); + } + + static int x86_pmu_event_idx(struct perf_event *event) +--- a/include/linux/perf_event.h ++++ b/include/linux/perf_event.h +@@ -310,8 +310,8 @@ struct pmu { + * Notification that the event was mapped or unmapped. Called + * in the context of the mapping task. + */ +- void (*event_mapped) (struct perf_event *event); /*optional*/ +- void (*event_unmapped) (struct perf_event *event); /*optional*/ ++ void (*event_mapped) (struct perf_event *event, struct mm_struct *mm); /* optional */ ++ void (*event_unmapped) (struct perf_event *event, struct mm_struct *mm); /* optional */ + + /* + * Flags for ->add()/->del()/ ->start()/->stop(). There are +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -5084,7 +5084,7 @@ static void perf_mmap_open(struct vm_are + atomic_inc(&event->rb->aux_mmap_count); + + if (event->pmu->event_mapped) +- event->pmu->event_mapped(event); ++ event->pmu->event_mapped(event, vma->vm_mm); + } + + static void perf_pmu_output_stop(struct perf_event *event); +@@ -5107,7 +5107,7 @@ static void perf_mmap_close(struct vm_ar + unsigned long size = perf_data_size(rb); + + if (event->pmu->event_unmapped) +- event->pmu->event_unmapped(event); ++ event->pmu->event_unmapped(event, vma->vm_mm); + + /* + * rb->aux_mmap_count will always drop before rb->mmap_count and +@@ -5405,7 +5405,7 @@ aux_unlock: + vma->vm_ops = &perf_mmap_vmops; + + if (event->pmu->event_mapped) +- event->pmu->event_mapped(event); ++ event->pmu->event_mapped(event, vma->vm_mm); + + return ret; + } diff --git a/queue-4.12/powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch b/queue-4.12/powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch new file mode 100644 index 00000000000..938ca693b1d --- /dev/null +++ b/queue-4.12/powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch @@ -0,0 +1,50 @@ +From 5a69aec945d27e78abac9fd032533d3aaebf7c1e Mon Sep 17 00:00:00 2001 +From: Benjamin Herrenschmidt +Date: Wed, 16 Aug 2017 16:01:14 +1000 +Subject: powerpc: Fix VSX enabling/flushing to also test MSR_FP and MSR_VEC + +From: Benjamin Herrenschmidt + +commit 5a69aec945d27e78abac9fd032533d3aaebf7c1e upstream. + +VSX uses a combination of the old vector registers, the old FP +registers and new "second halves" of the FP registers. + +Thus when we need to see the VSX state in the thread struct +(flush_vsx_to_thread()) or when we'll use the VSX in the kernel +(enable_kernel_vsx()) we need to ensure they are all flushed into +the thread struct if either of them is individually enabled. + +Unfortunately we only tested if the whole VSX was enabled, not if they +were individually enabled. + +Fixes: 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx() routine available") +Signed-off-by: Benjamin Herrenschmidt +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kernel/process.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/kernel/process.c ++++ b/arch/powerpc/kernel/process.c +@@ -362,7 +362,8 @@ void enable_kernel_vsx(void) + + cpumsr = msr_check_and_set(MSR_FP|MSR_VEC|MSR_VSX); + +- if (current->thread.regs && (current->thread.regs->msr & MSR_VSX)) { ++ if (current->thread.regs && ++ (current->thread.regs->msr & (MSR_VSX|MSR_VEC|MSR_FP))) { + check_if_tm_restore_required(current); + /* + * If a thread has already been reclaimed then the +@@ -386,7 +387,7 @@ void flush_vsx_to_thread(struct task_str + { + if (tsk->thread.regs) { + preempt_disable(); +- if (tsk->thread.regs->msr & MSR_VSX) { ++ if (tsk->thread.regs->msr & (MSR_VSX|MSR_VEC|MSR_FP)) { + BUG_ON(tsk != current); + giveup_vsx(tsk); + } diff --git a/queue-4.12/series b/queue-4.12/series index 66447c29b9c..98106a6b550 100644 --- a/queue-4.12/series +++ b/queue-4.12/series @@ -15,3 +15,22 @@ alsa-usb-audio-add-mute-tlv-for-playback-volumes-on-c-media-devices.patch alsa-usb-audio-add-dsd-support-for-new-amanero-pid.patch mm-discard-memblock-data-later.patch slub-fix-per-memcg-cache-leak-on-css-offline.patch +mm-fix-double-mmap_sem-unlock-on-mmf_unstable-enforced-sigbus.patch +mm-cma_debug.c-fix-stack-corruption-due-to-sprintf-usage.patch +mm-mempolicy-fix-use-after-free-when-calling-get_mempolicy.patch +mm-vmalloc.c-don-t-unconditonally-use-__gfp_highmem.patch +mm-revert-x86_64-and-arm64-elf_et_dyn_base-base-changes.patch +xen-fix-bio-vec-merging.patch +arm-dts-imx6qdl-nitrogen6_som2-fix-pcie-reset.patch +blk-mq-pci-add-a-fallback-when-pci_irq_get_affinity-returns-null.patch +powerpc-fix-vsx-enabling-flushing-to-also-test-msr_fp-and-msr_vec.patch +xen-blkfront-use-a-right-index-when-checking-requests.patch +perf-x86-fix-rdpmc-vs.-mm_struct-tracking.patch +x86-asm-64-clear-ac-on-nmi-entries.patch +x86-fix-norandmaps-addr_no_randomize.patch +x86-elf-remove-the-unnecessary-addr_no_randomize-checks.patch +irqchip-atmel-aic-fix-unbalanced-of_node_put-in-aic_common_irq_fixup.patch +irqchip-atmel-aic-fix-unbalanced-refcount-in-aic_common_rtc_irq_fixup.patch +genirq-restore-trigger-settings-in-irq_modify_status.patch +genirq-ipi-fixup-checks-against-nr_cpu_ids.patch +kernel-watchdog-prevent-false-positives-with-turbo-modes.patch diff --git a/queue-4.12/x86-asm-64-clear-ac-on-nmi-entries.patch b/queue-4.12/x86-asm-64-clear-ac-on-nmi-entries.patch new file mode 100644 index 00000000000..69d6fb3dc86 --- /dev/null +++ b/queue-4.12/x86-asm-64-clear-ac-on-nmi-entries.patch @@ -0,0 +1,41 @@ +From e93c17301ac55321fc18e0f8316e924e58a83c8c Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Mon, 7 Aug 2017 19:43:13 -0700 +Subject: x86/asm/64: Clear AC on NMI entries + +From: Andy Lutomirski + +commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream. + +This closes a hole in our SMAP implementation. + +This patch comes from grsecurity. Good catch! + +Signed-off-by: Andy Lutomirski +Cc: Borislav Petkov +Cc: Brian Gerst +Cc: Denys Vlasenko +Cc: H. Peter Anvin +Cc: Josh Poimboeuf +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/entry/entry_64.S | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/entry/entry_64.S ++++ b/arch/x86/entry/entry_64.S +@@ -1209,6 +1209,8 @@ ENTRY(nmi) + * other IST entries. + */ + ++ ASM_CLAC ++ + /* Use %rdx as our temp variable throughout */ + pushq %rdx + diff --git a/queue-4.12/x86-elf-remove-the-unnecessary-addr_no_randomize-checks.patch b/queue-4.12/x86-elf-remove-the-unnecessary-addr_no_randomize-checks.patch new file mode 100644 index 00000000000..af27c1c23c0 --- /dev/null +++ b/queue-4.12/x86-elf-remove-the-unnecessary-addr_no_randomize-checks.patch @@ -0,0 +1,55 @@ +From 01578e36163cdd0e4fd61d9976de15f13364e26d Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov +Date: Tue, 15 Aug 2017 17:40:11 +0200 +Subject: x86/elf: Remove the unnecessary ADDR_NO_RANDOMIZE checks + +From: Oleg Nesterov + +commit 01578e36163cdd0e4fd61d9976de15f13364e26d upstream. + +The ADDR_NO_RANDOMIZE checks in stack_maxrandom_size() and +randomize_stack_top() are not required. + +PF_RANDOMIZE is set by load_elf_binary() only if ADDR_NO_RANDOMIZE is not +set, no need to re-check after that. + +Signed-off-by: Oleg Nesterov +Signed-off-by: Thomas Gleixner +Reviewed-by: Dmitry Safonov +Cc: Andy Lutomirski +Cc: Andrew Morton +Cc: Borislav Petkov +Cc: Linus Torvalds +Cc: "Kirill A. Shutemov" +Link: http://lkml.kernel.org/r/20170815154011.GB1076@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/mm/mmap.c | 3 +-- + fs/binfmt_elf.c | 3 +-- + 2 files changed, 2 insertions(+), 4 deletions(-) + +--- a/arch/x86/mm/mmap.c ++++ b/arch/x86/mm/mmap.c +@@ -50,8 +50,7 @@ unsigned long tasksize_64bit(void) + static unsigned long stack_maxrandom_size(unsigned long task_size) + { + unsigned long max = 0; +- if ((current->flags & PF_RANDOMIZE) && +- !(current->personality & ADDR_NO_RANDOMIZE)) { ++ if (current->flags & PF_RANDOMIZE) { + max = (-1UL) & __STACK_RND_MASK(task_size == tasksize_32bit()); + max <<= PAGE_SHIFT; + } +--- a/fs/binfmt_elf.c ++++ b/fs/binfmt_elf.c +@@ -666,8 +666,7 @@ static unsigned long randomize_stack_top + { + unsigned long random_variable = 0; + +- if ((current->flags & PF_RANDOMIZE) && +- !(current->personality & ADDR_NO_RANDOMIZE)) { ++ if (current->flags & PF_RANDOMIZE) { + random_variable = get_random_long(); + random_variable &= STACK_RND_MASK; + random_variable <<= PAGE_SHIFT; diff --git a/queue-4.12/x86-fix-norandmaps-addr_no_randomize.patch b/queue-4.12/x86-fix-norandmaps-addr_no_randomize.patch new file mode 100644 index 00000000000..5809c10a41f --- /dev/null +++ b/queue-4.12/x86-fix-norandmaps-addr_no_randomize.patch @@ -0,0 +1,55 @@ +From 47ac5484fd961420e5ec0bb5b972fde381f57365 Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov +Date: Tue, 15 Aug 2017 17:39:52 +0200 +Subject: x86: Fix norandmaps/ADDR_NO_RANDOMIZE + +From: Oleg Nesterov + +commit 47ac5484fd961420e5ec0bb5b972fde381f57365 upstream. + +Documentation/admin-guide/kernel-parameters.txt says: + + norandmaps Don't use address space randomization. Equivalent + to echo 0 > /proc/sys/kernel/randomize_va_space + +but it doesn't work because arch_rnd() which is used to randomize +mm->mmap_base returns a random value unconditionally. And as Kirill +pointed out, ADDR_NO_RANDOMIZE is broken by the same reason. + +Just shift the PF_RANDOMIZE check from arch_mmap_rnd() to arch_rnd(). + +Fixes: 1b028f784e8c ("x86/mm: Introduce mmap_compat_base() for 32-bit mmap()") +Signed-off-by: Oleg Nesterov +Signed-off-by: Thomas Gleixner +Acked-by: Kirill A. Shutemov +Acked-by: Cyrill Gorcunov +Reviewed-by: Dmitry Safonov +Cc: Andy Lutomirski +Cc: Andrew Morton +Cc: Borislav Petkov +Cc: Linus Torvalds +Link: http://lkml.kernel.org/r/20170815153952.GA1076@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/mm/mmap.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/mm/mmap.c ++++ b/arch/x86/mm/mmap.c +@@ -82,13 +82,13 @@ static int mmap_is_legacy(void) + + static unsigned long arch_rnd(unsigned int rndbits) + { ++ if (!(current->flags & PF_RANDOMIZE)) ++ return 0; + return (get_random_long() & ((1UL << rndbits) - 1)) << PAGE_SHIFT; + } + + unsigned long arch_mmap_rnd(void) + { +- if (!(current->flags & PF_RANDOMIZE)) +- return 0; + return arch_rnd(mmap_is_ia32() ? mmap32_rnd_bits : mmap64_rnd_bits); + } + diff --git a/queue-4.12/xen-blkfront-use-a-right-index-when-checking-requests.patch b/queue-4.12/xen-blkfront-use-a-right-index-when-checking-requests.patch new file mode 100644 index 00000000000..9b487c863a8 --- /dev/null +++ b/queue-4.12/xen-blkfront-use-a-right-index-when-checking-requests.patch @@ -0,0 +1,75 @@ +From b15bd8cb37598afb2963f7eb9e2de468d2d60a2f Mon Sep 17 00:00:00 2001 +From: Munehisa Kamata +Date: Wed, 9 Aug 2017 15:31:40 -0700 +Subject: xen-blkfront: use a right index when checking requests + +From: Munehisa Kamata + +commit b15bd8cb37598afb2963f7eb9e2de468d2d60a2f upstream. + +Since commit d05d7f40791c ("Merge branch 'for-4.8/core' of +git://git.kernel.dk/linux-block") and 3fc9d690936f ("Merge branch +'for-4.8/drivers' of git://git.kernel.dk/linux-block"), blkfront_resume() +has been using an index for iterating ring_info to check request when +iterating blk_shadow in an inner loop. This seems to have been +accidentally introduced during the massive rewrite of the block layer +macros in the commits. + +This may cause crash like this: + +[11798.057074] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 +[11798.058832] IP: [] blkfront_resume+0x10a/0x610 +.... +[11798.061063] Call Trace: +[11798.061063] [] xenbus_dev_resume+0x53/0x140 +[11798.061063] [] ? xenbus_dev_probe+0x150/0x150 +[11798.061063] [] dpm_run_callback+0x3e/0x110 +[11798.061063] [] device_resume+0x88/0x190 +[11798.061063] [] dpm_resume+0x100/0x2d0 +[11798.061063] [] dpm_resume_end+0x11/0x20 +[11798.061063] [] do_suspend+0xe8/0x1a0 +[11798.061063] [] shutdown_handler+0xfd/0x130 +[11798.061063] [] ? split+0x110/0x110 +[11798.061063] [] xenwatch_thread+0x86/0x120 +[11798.061063] [] ? prepare_to_wait_event+0x110/0x110 +[11798.061063] [] kthread+0xd7/0xf0 +[11798.061063] [] ? kfree+0x121/0x170 +[11798.061063] [] ? kthread_park+0x60/0x60 +[11798.061063] [] ? call_usermodehelper_exec_work+0xb0/0xb0 +[11798.061063] [] ? call_usermodehelper_exec_async+0x13a/0x140 +[11798.061063] [] ret_from_fork+0x25/0x30 + +Use the right index in the inner loop. + +Fixes: d05d7f40791c ("Merge branch 'for-4.8/core' of git://git.kernel.dk/linux-block") +Fixes: 3fc9d690936f ("Merge branch 'for-4.8/drivers' of git://git.kernel.dk/linux-block") +Signed-off-by: Munehisa Kamata +Reviewed-by: Thomas Friebel +Reviewed-by: Eduardo Valentin +Reviewed-by: Boris Ostrovsky +Cc: Juergen Gross +Cc: Konrad Rzeszutek Wilk +Reviewed-by: Roger Pau Monne +Cc: xen-devel@lists.xenproject.org +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/xen-blkfront.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/block/xen-blkfront.c ++++ b/drivers/block/xen-blkfront.c +@@ -2119,9 +2119,9 @@ static int blkfront_resume(struct xenbus + /* + * Get the bios in the request so we can re-queue them. + */ +- if (req_op(shadow[i].request) == REQ_OP_FLUSH || +- req_op(shadow[i].request) == REQ_OP_DISCARD || +- req_op(shadow[i].request) == REQ_OP_SECURE_ERASE || ++ if (req_op(shadow[j].request) == REQ_OP_FLUSH || ++ req_op(shadow[j].request) == REQ_OP_DISCARD || ++ req_op(shadow[j].request) == REQ_OP_SECURE_ERASE || + shadow[j].request->cmd_flags & REQ_FUA) { + /* + * Flush operations don't contain bios, so diff --git a/queue-4.12/xen-fix-bio-vec-merging.patch b/queue-4.12/xen-fix-bio-vec-merging.patch new file mode 100644 index 00000000000..c8968b69ee6 --- /dev/null +++ b/queue-4.12/xen-fix-bio-vec-merging.patch @@ -0,0 +1,61 @@ +From 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 Mon Sep 17 00:00:00 2001 +From: Roger Pau Monne +Date: Tue, 18 Jul 2017 15:01:00 +0100 +Subject: xen: fix bio vec merging +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Roger Pau Monne + +commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream. + +The current test for bio vec merging is not fully accurate and can be +tricked into merging bios when certain grant combinations are used. +The result of these malicious bio merges is a bio that extends past +the memory page used by any of the originating bios. + +Take into account the following scenario, where a guest creates two +grant references that point to the same mfn, ie: grant 1 -> mfn A, +grant 2 -> mfn A. + +These references are then used in a PV block request, and mapped by +the backend domain, thus obtaining two different pfns that point to +the same mfn, pfn B -> mfn A, pfn C -> mfn A. + +If those grants happen to be used in two consecutive sectors of a disk +IO operation becoming two different bios in the backend domain, the +checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2 +(they both point to the same mfn). However due to the bio merging, +the backend domain will end up with a bio that expands past mfn A into +mfn A + 1. + +Fix this by making sure the check in xen_biovec_phys_mergeable takes +into account the offset and the length of the bio, this basically +replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus +addresses). While there also remove the usage of +__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers +of xen_biovec_phys_mergeable. + +Reported-by: "Jan H. Schönherr" +Signed-off-by: Roger Pau Monné +Reviewed-by: Juergen Gross +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/xen/biomerge.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/xen/biomerge.c ++++ b/drivers/xen/biomerge.c +@@ -10,8 +10,7 @@ bool xen_biovec_phys_mergeable(const str + unsigned long bfn1 = pfn_to_bfn(page_to_pfn(vec1->bv_page)); + unsigned long bfn2 = pfn_to_bfn(page_to_pfn(vec2->bv_page)); + +- return __BIOVEC_PHYS_MERGEABLE(vec1, vec2) && +- ((bfn1 == bfn2) || ((bfn1+1) == bfn2)); ++ return bfn1 + PFN_DOWN(vec1->bv_offset + vec1->bv_len) == bfn2; + #else + /* + * XXX: Add support for merging bio_vec when using different page