From 5c0180e7122c50fb26eb61f4aa464a544adda8cc Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 17 Oct 2015 12:07:45 -0700 Subject: [PATCH] 3.10-stable patches added patches: mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch spi-fix-documentation-of-spi_alloc_master.patch spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch --- ...ing-private-pages-to-satisfy-a-fault.patch | 87 +++++++++++++++++++ queue-3.10/series | 3 + ...ix-documentation-of-spi_alloc_master.patch | 47 ++++++++++ ...o-determine-if-sssr_tint-is-disabled.patch | 46 ++++++++++ 4 files changed, 183 insertions(+) create mode 100644 queue-3.10/mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch create mode 100644 queue-3.10/spi-fix-documentation-of-spi_alloc_master.patch create mode 100644 queue-3.10/spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch diff --git a/queue-3.10/mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch b/queue-3.10/mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch new file mode 100644 index 00000000000..3e6dca4fd23 --- /dev/null +++ b/queue-3.10/mm-hugetlbfs-skip-shared-vmas-when-unmapping-private-pages-to-satisfy-a-fault.patch @@ -0,0 +1,87 @@ +From 2f84a8990ebbe235c59716896e017c6b2ca1200f Mon Sep 17 00:00:00 2001 +From: Mel Gorman +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 + +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 +Reported-by: SunDong +Reviewed-by: Michal Hocko +Cc: Andrea Arcangeli +Cc: Hugh Dickins +Cc: Naoya Horiguchi +Cc: David Rientjes +Reviewed-by: Naoya Horiguchi +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-3.10/series b/queue-3.10/series index 216183c06ff..de5e7077b52 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -7,3 +7,6 @@ x86-platform-fix-geode-lx-timekeeping-in-the-generic-x86-build.patch 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 diff --git a/queue-3.10/spi-fix-documentation-of-spi_alloc_master.patch b/queue-3.10/spi-fix-documentation-of-spi_alloc_master.patch new file mode 100644 index 00000000000..2444b6836ba --- /dev/null +++ b/queue-3.10/spi-fix-documentation-of-spi_alloc_master.patch @@ -0,0 +1,47 @@ +From a394d635193b641f2c86ead5ada5b115d57c51f8 Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Sun, 6 Sep 2015 01:46:54 +0300 +Subject: spi: Fix documentation of spi_alloc_master() + +From: Guenter Roeck + +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 +Signed-off-by: Alexey Klimov +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + 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) + { diff --git a/queue-3.10/spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch b/queue-3.10/spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch new file mode 100644 index 00000000000..dcbf8351e00 --- /dev/null +++ b/queue-3.10/spi-spi-pxa2xx-check-status-register-to-determine-if-sssr_tint-is-disabled.patch @@ -0,0 +1,46 @@ +From 02bc933ebb59208f42c2e6305b2c17fd306f695d Mon Sep 17 00:00:00 2001 +From: "Tan, Jui Nee" +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" + +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 +Acked-by: Jarkko Nikula +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + -- 2.47.3