--- /dev/null
+From 2f84a8990ebbe235c59716896e017c6b2ca1200f Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@techsingularity.net>
+Date: Thu, 1 Oct 2015 15:36:57 -0700
+Subject: mm: hugetlbfs: skip shared VMAs when unmapping private pages to satisfy a fault
+
+From: Mel Gorman <mgorman@techsingularity.net>
+
+commit 2f84a8990ebbe235c59716896e017c6b2ca1200f upstream.
+
+SunDong reported the following on
+
+ https://bugzilla.kernel.org/show_bug.cgi?id=103841
+
+ I think I find a linux bug, I have the test cases is constructed. I
+ can stable recurring problems in fedora22(4.0.4) kernel version,
+ arch for x86_64. I construct transparent huge page, when the parent
+ and child process with MAP_SHARE, MAP_PRIVATE way to access the same
+ huge page area, it has the opportunity to lead to huge page copy on
+ write failure, and then it will munmap the child corresponding mmap
+ area, but then the child mmap area with VM_MAYSHARE attributes, child
+ process munmap this area can trigger VM_BUG_ON in set_vma_resv_flags
+ functions (vma - > vm_flags & VM_MAYSHARE).
+
+There were a number of problems with the report (e.g. it's hugetlbfs that
+triggers this, not transparent huge pages) but it was fundamentally
+correct in that a VM_BUG_ON in set_vma_resv_flags() can be triggered that
+looks like this
+
+ vma ffff8804651fd0d0 start 00007fc474e00000 end 00007fc475e00000
+ next ffff8804651fd018 prev ffff8804651fd188 mm ffff88046b1b1800
+ prot 8000000000000027 anon_vma (null) vm_ops ffffffff8182a7a0
+ pgoff 0 file ffff88106bdb9800 private_data (null)
+ flags: 0x84400fb(read|write|shared|mayread|maywrite|mayexec|mayshare|dontexpand|hugetlb)
+ ------------
+ kernel BUG at mm/hugetlb.c:462!
+ SMP
+ Modules linked in: xt_pkttype xt_LOG xt_limit [..]
+ CPU: 38 PID: 26839 Comm: map Not tainted 4.0.4-default #1
+ Hardware name: Dell Inc. PowerEdge R810/0TT6JF, BIOS 2.7.4 04/26/2012
+ set_vma_resv_flags+0x2d/0x30
+
+The VM_BUG_ON is correct because private and shared mappings have
+different reservation accounting but the warning clearly shows that the
+VMA is shared.
+
+When a private COW fails to allocate a new page then only the process
+that created the VMA gets the page -- all the children unmap the page.
+If the children access that data in the future then they get killed.
+
+The problem is that the same file is mapped shared and private. During
+the COW, the allocation fails, the VMAs are traversed to unmap the other
+private pages but a shared VMA is found and the bug is triggered. This
+patch identifies such VMAs and skips them.
+
+Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
+Reported-by: SunDong <sund_sky@126.com>
+Reviewed-by: Michal Hocko <mhocko@suse.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Cc: David Rientjes <rientjes@google.com>
+Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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/hugetlb.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -2573,6 +2573,14 @@ static int unmap_ref_private(struct mm_s
+ continue;
+
+ /*
++ * Shared VMAs have their own reserves and do not affect
++ * MAP_PRIVATE accounting but it is possible that a shared
++ * VMA is using the same page so check and skip such VMAs.
++ */
++ if (iter_vma->vm_flags & VM_MAYSHARE)
++ continue;
++
++ /*
+ * Unmap the page from other VMAs without their own reserves.
+ * They get marked to be SIGKILLed if they fault in these
+ * areas. This is because a future no-page fault on this VMA
use-warn_on_once-for-missing-x86_feature_nrips.patch
x86-mm-set-nx-on-gap-between-__ex_table-and-rodata.patch
x86-xen-support-kexec-kdump-in-hvm-guests-by-doing-a-soft-reset.patch
+spi-fix-documentation-of-spi_alloc_master.patch
+spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch
+mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch
--- /dev/null
+From a394d635193b641f2c86ead5ada5b115d57c51f8 Mon Sep 17 00:00:00 2001
+From: Guenter Roeck <linux@roeck-us.net>
+Date: Sun, 6 Sep 2015 01:46:54 +0300
+Subject: spi: Fix documentation of spi_alloc_master()
+
+From: Guenter Roeck <linux@roeck-us.net>
+
+commit a394d635193b641f2c86ead5ada5b115d57c51f8 upstream.
+
+Actually, spi_master_put() after spi_alloc_master() must _not_ be followed
+by kfree(). The memory is already freed with the call to spi_master_put()
+through spi_master_class, which registers a release function. Calling both
+spi_master_put() and kfree() results in often nasty (and delayed) crashes
+elsewhere in the kernel, often in the networking stack.
+
+This reverts commit eb4af0f5349235df2e4a5057a72fc8962d00308a.
+
+Link to patch and concerns: https://lkml.org/lkml/2012/9/3/269
+or
+http://lkml.iu.edu/hypermail/linux/kernel/1209.0/00790.html
+
+Alexey Klimov: This revert becomes valid after
+94c69f765f1b4a658d96905ec59928e3e3e07e6a when spi-imx.c
+has been fixed and there is no need to call kfree() so comment
+for spi_alloc_master() should be fixed.
+
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -1030,8 +1030,7 @@ static struct class spi_master_class = {
+ *
+ * The caller is responsible for assigning the bus number and initializing
+ * the master's methods before calling spi_register_master(); and (after errors
+- * adding the device) calling spi_master_put() and kfree() to prevent a memory
+- * leak.
++ * adding the device) calling spi_master_put() to prevent a memory leak.
+ */
+ struct spi_master *spi_alloc_master(struct device *dev, unsigned size)
+ {
--- /dev/null
+From 02bc933ebb59208f42c2e6305b2c17fd306f695d Mon Sep 17 00:00:00 2001
+From: "Tan, Jui Nee" <jui.nee.tan@intel.com>
+Date: Tue, 1 Sep 2015 10:22:51 +0800
+Subject: spi: spi-pxa2xx: Check status register to determine if SSSR_TINT is disabled
+
+From: "Tan, Jui Nee" <jui.nee.tan@intel.com>
+
+commit 02bc933ebb59208f42c2e6305b2c17fd306f695d upstream.
+
+On Intel Baytrail, there is case when interrupt handler get called, no SPI
+message is captured. The RX FIFO is indeed empty when RX timeout pending
+interrupt (SSSR_TINT) happens.
+
+Use the BIOS version where both HSUART and SPI are on the same IRQ. Both
+drivers are using IRQF_SHARED when calling the request_irq function. When
+running two separate and independent SPI and HSUART application that
+generate data traffic on both components, user will see messages like
+below on the console:
+
+ pxa2xx-spi pxa2xx-spi.0: bad message state in interrupt handler
+
+This commit will fix this by first checking Receiver Time-out Interrupt,
+if it is disabled, ignore the request and return without servicing.
+
+Signed-off-by: Tan, Jui Nee <jui.nee.tan@intel.com>
+Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/spi/spi-pxa2xx.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/spi/spi-pxa2xx.c
++++ b/drivers/spi/spi-pxa2xx.c
+@@ -546,6 +546,10 @@ static irqreturn_t ssp_int(int irq, void
+ if (!(sccr1_reg & SSCR1_TIE))
+ mask &= ~SSSR_TFS;
+
++ /* Ignore RX timeout interrupt if it is disabled */
++ if (!(sccr1_reg & SSCR1_TINTE))
++ mask &= ~SSSR_TINT;
++
+ if (!(status & mask))
+ return IRQ_NONE;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
