From: Greg Kroah-Hartman Date: Tue, 29 Jul 2014 05:50:24 +0000 (-0700) Subject: 3.4-stable patches X-Git-Tag: v3.15.8~13 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bf4739b408c762a99da3ffecfded963f92a09f97;p=thirdparty%2Fkernel%2Fstable-queue.git 3.4-stable patches added patches: fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch mm-hugetlb-fix-copy_hugetlb_page_range.patch --- diff --git a/queue-3.4/fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch b/queue-3.4/fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch new file mode 100644 index 00000000000..54592091a6f --- /dev/null +++ b/queue-3.4/fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch @@ -0,0 +1,70 @@ +From 2062afb4f804afef61cbe62a30cac9a46e58e067 Mon Sep 17 00:00:00 2001 +From: Linus Torvalds +Date: Sat, 26 Jul 2014 14:52:01 -0700 +Subject: Fix gcc-4.9.0 miscompilation of load_balance() in scheduler +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Linus Torvalds + +commit 2062afb4f804afef61cbe62a30cac9a46e58e067 upstream. + +Michel Dänzer and a couple of other people reported inexplicable random +oopses in the scheduler, and the cause turns out to be gcc mis-compiling +the load_balance() function when debugging is enabled. The gcc bug +apparently goes back to gcc-4.5, but slight optimization changes means +that it now showed up as a problem in 4.9.0 and 4.9.1. + +The instruction scheduling problem causes gcc to schedule a spill +operation to before the stack frame has been created, which in turn can +corrupt the spilled value if an interrupt comes in. There may be other +effects of this bug too, but that's the code generation problem seen in +Michel's case. + +This is fixed in current gcc HEAD, but the workaround as suggested by +Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments +when compiling the kernel, which disables the gcc code that causes the +problem. This can result in slightly worse debug information for +variable accesses, but that is infinitely preferable to actual code +generation problems. + +Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows +non-debug builds to verify that the debug build would be identical: we +can do + + export GCC_COMPARE_DEBUG=1 + +to make gcc internally verify that the result of the build is +independent of the "-g" flag (it will make the compiler build everything +twice, toggling the debug flag, and compare the results). + +Without the "-fno-var-tracking-assignments" option, the build would fail +(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc +compare failure. + +See also gcc bugzilla: + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 + +Reported-by: Michel Dänzer +Suggested-by: Markus Trippelsdorf +Cc: Jakub Jelinek +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + Makefile | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/Makefile ++++ b/Makefile +@@ -592,6 +592,8 @@ KBUILD_CFLAGS += -fomit-frame-pointer + endif + endif + ++KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments) ++ + ifdef CONFIG_DEBUG_INFO + KBUILD_CFLAGS += -g + KBUILD_AFLAGS += -gdwarf-2 diff --git a/queue-3.4/mm-hugetlb-fix-copy_hugetlb_page_range.patch b/queue-3.4/mm-hugetlb-fix-copy_hugetlb_page_range.patch new file mode 100644 index 00000000000..ee5c5aecea2 --- /dev/null +++ b/queue-3.4/mm-hugetlb-fix-copy_hugetlb_page_range.patch @@ -0,0 +1,70 @@ +From 0253d634e0803a8376a0d88efee0bf523d8673f9 Mon Sep 17 00:00:00 2001 +From: Naoya Horiguchi +Date: Wed, 23 Jul 2014 14:00:19 -0700 +Subject: mm: hugetlb: fix copy_hugetlb_page_range() + +From: Naoya Horiguchi + +commit 0253d634e0803a8376a0d88efee0bf523d8673f9 upstream. + +Commit 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle +migration/hwpoisoned entry") changed the order of +huge_ptep_set_wrprotect() and huge_ptep_get(), which leads to breakage +in some workloads like hugepage-backed heap allocation via libhugetlbfs. +This patch fixes it. + +The test program for the problem is shown below: + + $ cat heap.c + #include + #include + #include + + #define HPS 0x200000 + + int main() { + int i; + char *p = malloc(HPS); + memset(p, '1', HPS); + for (i = 0; i < 5; i++) { + if (!fork()) { + memset(p, '2', HPS); + p = malloc(HPS); + memset(p, '3', HPS); + free(p); + return 0; + } + } + sleep(1); + free(p); + return 0; + } + + $ export HUGETLB_MORECORE=yes ; export HUGETLB_NO_PREFAULT= ; hugectl --heap ./heap + +Fixes 4a705fef9862 ("hugetlb: fix copy_hugetlb_page_range() to handle +migration/hwpoisoned entry"), so is applicable to -stable kernels which +include it. + +Signed-off-by: Naoya Horiguchi +Reported-by: Guillaume Morin +Suggested-by: Guillaume Morin +Acked-by: Hugh Dickins +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/hugetlb.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -2348,6 +2348,7 @@ int copy_hugetlb_page_range(struct mm_st + } else { + if (cow) + huge_ptep_set_wrprotect(src, addr, src_pte); ++ entry = huge_ptep_get(src_pte); + ptepage = pte_page(entry); + get_page(ptepage); + page_dup_rmap(ptepage); diff --git a/queue-3.4/series b/queue-3.4/series index 0c7aedfb8a5..d6e1577fcf4 100644 --- a/queue-3.4/series +++ b/queue-3.4/series @@ -4,3 +4,5 @@ libata-introduce-ata_host-n_tags-to-avoid-oops-on-sas-controllers.patch s390-ptrace-fix-psw-mask-check.patch ahci-add-support-for-the-promise-fasttrak-tx8660-sata-hba-ahci-mode.patch x86_32-entry-store-badsys-error-code-in-eax.patch +mm-hugetlb-fix-copy_hugetlb_page_range.patch +fix-gcc-4.9.0-miscompilation-of-load_balance-in-scheduler.patch