--- /dev/null
+From c40bc54fdf2d52a80f66b365f1eac9d43b32e107 Mon Sep 17 00:00:00 2001
+From: Gary Bisson <gary.bisson@boundarydevices.com>
+Date: Thu, 17 Aug 2017 15:50:10 +0200
+Subject: ARM: dts: imx6qdl-nitrogen6_som2: fix PCIe reset
+
+From: Gary Bisson <gary.bisson@boundarydevices.com>
+
+commit c40bc54fdf2d52a80f66b365f1eac9d43b32e107 upstream.
+
+Previous value was a bad copy of nitrogen6_max device tree.
+
+Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
+Fixes: 3faa1bb2e89c ("ARM: dts: imx: add Boundary Devices Nitrogen6_SOM2 support")
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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";
+ };
+
--- /dev/null
+From c005390374957baacbc38eef96ea360559510aa7 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+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 <hch@lst.de>
+
+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 <hch@lst.de>
+Reviewed-by: Omar Sandoval <osandov@fb.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 8fbbe2d7cc478d1544f41f2271787c993c23a4f6 Mon Sep 17 00:00:00 2001
+From: Alexey Dobriyan <adobriyan@gmail.com>
+Date: Sat, 19 Aug 2017 12:57:51 +0300
+Subject: genirq/ipi: Fixup checks against nr_cpu_ids
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+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 <adobriyan@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/20170819095751.GB27864@avx2
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From e8f241893dfbbebe2813c01eac54f263e6a5e59c Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Fri, 18 Aug 2017 10:53:45 +0100
+Subject: genirq: Restore trigger settings in irq_modify_status()
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+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 <jeffy.chen@rock-chips.com>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Jon Hunter <jonathanh@nvidia.com>
+Link: http://lkml.kernel.org/r/20170818095345.12378-1-marc.zyngier@arm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From 469bcef53c546bb792aa66303933272991b7831d Mon Sep 17 00:00:00 2001
+From: Boris Brezillon <boris.brezillon@free-electrons.com>
+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 <boris.brezillon@free-electrons.com>
+
+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 <boris.brezillon@free-electrons.com>
+Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Fixes: b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup infrastructure")
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 277867ade8262583f4280cadbe90e0031a3706a7 Mon Sep 17 00:00:00 2001
+From: Boris Brezillon <boris.brezillon@free-electrons.com>
+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 <boris.brezillon@free-electrons.com>
+
+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 <boris.brezillon@free-electrons.com>
+Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
+Fixes: 3d61467f9bab ("irqchip: atmel-aic: Implement RTC irq fixup")
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 7edaeb6841dfb27e362288ab8466ebdc4972e867 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 15 Aug 2017 09:50:13 +0200
+Subject: kernel/watchdog: Prevent false positives with turbo modes
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <Kan.liang@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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):
--- /dev/null
+From da094e42848e3c36feaa3b5271e53983fd45424f Mon Sep 17 00:00:00 2001
+From: Prakash Gupta <guptap@codeaurora.org>
+Date: Fri, 18 Aug 2017 15:16:21 -0700
+Subject: mm/cma_debug.c: fix stack corruption due to sprintf usage
+
+From: Prakash Gupta <guptap@codeaurora.org>
+
+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 <guptap@codeaurora.org>
+Acked-by: Laura Abbott <labbott@redhat.com>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+
--- /dev/null
+From 5b53a6ea886700a128b697a6fe8375340dea2c30 Mon Sep 17 00:00:00 2001
+From: Michal Hocko <mhocko@suse.com>
+Date: Fri, 18 Aug 2017 15:16:12 -0700
+Subject: mm: fix double mmap_sem unlock on MMF_UNSTABLE enforced SIGBUS
+
+From: Michal Hocko <mhocko@suse.com>
+
+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 <penguin-kernel@i-love.sakura.ne.jp>
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Acked-by: David Rientjes <rientjes@google.com>
+Cc: Andrea Argangeli <andrea@kernel.org>
+Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Cc: Wenwei Tao <wenwei.tww@alibaba-inc.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 73223e4e2e3867ebf033a5a8eb2e5df0158ccc99 Mon Sep 17 00:00:00 2001
+From: zhong jiang <zhongjiang@huawei.com>
+Date: Fri, 18 Aug 2017 15:16:24 -0700
+Subject: mm/mempolicy: fix use after free when calling get_mempolicy
+
+From: zhong jiang <zhongjiang@huawei.com>
+
+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 <zhongjiang@huawei.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: David Rientjes <rientjes@google.com>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)) {
--- /dev/null
+From c715b72c1ba406f133217b509044c38d8e714a37 Mon Sep 17 00:00:00 2001
+From: Kees Cook <keescook@chromium.org>
+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 <keescook@chromium.org>
+
+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 <keescook@chromium.org>
+Reported-by: Kostya Serebryany <kcc@google.com>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 704b862f9efd6d4c87a8d0a344dda19bda9c6b69 Mon Sep 17 00:00:00 2001
+From: Laura Abbott <labbott@redhat.com>
+Date: Fri, 18 Aug 2017 15:16:27 -0700
+Subject: mm/vmalloc.c: don't unconditonally use __GFP_HIGHMEM
+
+From: Laura Abbott <labbott@redhat.com>
+
+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 <labbott@redhat.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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();
+ }
+
--- /dev/null
+From bfe334924ccd9f4a53f30240c03cf2f43f5b2df1 Mon Sep 17 00:00:00 2001
+From: Peter Zijlstra <peterz@infradead.org>
+Date: Wed, 2 Aug 2017 19:39:30 +0200
+Subject: perf/x86: Fix RDPMC vs. mm_struct tracking
+
+From: Peter Zijlstra <peterz@infradead.org>
+
+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 <vincent.weaver@maine.edu>
+Tested-by: Vince Weaver <vincent.weaver@maine.edu>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Andy Lutomirski <luto@kernel.org>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@gmail.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 5a69aec945d27e78abac9fd032533d3aaebf7c1e Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+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 <benh@kernel.crashing.org>
+
+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 <benh@kernel.crashing.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
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
--- /dev/null
+From e93c17301ac55321fc18e0f8316e924e58a83c8c Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Mon, 7 Aug 2017 19:43:13 -0700
+Subject: x86/asm/64: Clear AC on NMI entries
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream.
+
+This closes a hole in our SMAP implementation.
+
+This patch comes from grsecurity. Good catch!
+
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+
--- /dev/null
+From 01578e36163cdd0e4fd61d9976de15f13364e26d Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Tue, 15 Aug 2017 17:40:11 +0200
+Subject: x86/elf: Remove the unnecessary ADDR_NO_RANDOMIZE checks
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+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 <oleg@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
+Link: http://lkml.kernel.org/r/20170815154011.GB1076@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 47ac5484fd961420e5ec0bb5b972fde381f57365 Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Tue, 15 Aug 2017 17:39:52 +0200
+Subject: x86: Fix norandmaps/ADDR_NO_RANDOMIZE
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+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 <oleg@redhat.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
+Reviewed-by: Dmitry Safonov <dsafonov@virtuozzo.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: http://lkml.kernel.org/r/20170815153952.GA1076@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From b15bd8cb37598afb2963f7eb9e2de468d2d60a2f Mon Sep 17 00:00:00 2001
+From: Munehisa Kamata <kamatam@amazon.com>
+Date: Wed, 9 Aug 2017 15:31:40 -0700
+Subject: xen-blkfront: use a right index when checking requests
+
+From: Munehisa Kamata <kamatam@amazon.com>
+
+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: [<ffffffff814411fa>] blkfront_resume+0x10a/0x610
+....
+[11798.061063] Call Trace:
+[11798.061063] [<ffffffff8139ce93>] xenbus_dev_resume+0x53/0x140
+[11798.061063] [<ffffffff8139ce40>] ? xenbus_dev_probe+0x150/0x150
+[11798.061063] [<ffffffff813f359e>] dpm_run_callback+0x3e/0x110
+[11798.061063] [<ffffffff813f3a08>] device_resume+0x88/0x190
+[11798.061063] [<ffffffff813f4cc0>] dpm_resume+0x100/0x2d0
+[11798.061063] [<ffffffff813f5221>] dpm_resume_end+0x11/0x20
+[11798.061063] [<ffffffff813950a8>] do_suspend+0xe8/0x1a0
+[11798.061063] [<ffffffff813954bd>] shutdown_handler+0xfd/0x130
+[11798.061063] [<ffffffff8139aba0>] ? split+0x110/0x110
+[11798.061063] [<ffffffff8139ac26>] xenwatch_thread+0x86/0x120
+[11798.061063] [<ffffffff810b4570>] ? prepare_to_wait_event+0x110/0x110
+[11798.061063] [<ffffffff8108fe57>] kthread+0xd7/0xf0
+[11798.061063] [<ffffffff811da811>] ? kfree+0x121/0x170
+[11798.061063] [<ffffffff8108fd80>] ? kthread_park+0x60/0x60
+[11798.061063] [<ffffffff810863b0>] ? call_usermodehelper_exec_work+0xb0/0xb0
+[11798.061063] [<ffffffff810864ea>] ? call_usermodehelper_exec_async+0x13a/0x140
+[11798.061063] [<ffffffff81534a45>] 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 <kamatam@amazon.com>
+Reviewed-by: Thomas Friebel <friebelt@amazon.de>
+Reviewed-by: Eduardo Valentin <eduval@amazon.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Cc: Juergen Gross <jgross@suse.com>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Reviewed-by: Roger Pau Monne <roger.pau@citrix.com>
+Cc: xen-devel@lists.xenproject.org
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
--- /dev/null
+From 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 Mon Sep 17 00:00:00 2001
+From: Roger Pau Monne <roger.pau@citrix.com>
+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 <roger.pau@citrix.com>
+
+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" <jschoenh@amazon.de>
+Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
