--- /dev/null
+From 4797ec2dc83a43be35bad56037d1b53db9e2b5d5 Mon Sep 17 00:00:00 2001
+From: Mark Salter <msalter@redhat.com>
+Date: Thu, 15 May 2014 15:19:22 +0100
+Subject: arm64: fix pud_huge() for 2-level pagetables
+
+From: Mark Salter <msalter@redhat.com>
+
+commit 4797ec2dc83a43be35bad56037d1b53db9e2b5d5 upstream.
+
+The following happens when trying to run a kvm guest on a kernel
+configured for 64k pages. This doesn't happen with 4k pages:
+
+ BUG: failure at include/linux/mm.h:297/put_page_testzero()!
+ Kernel panic - not syncing: BUG!
+ CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
+ Call trace:
+ [<fffffe0000096034>] dump_backtrace+0x0/0x16c
+ [<fffffe00000961b4>] show_stack+0x14/0x1c
+ [<fffffe000066e648>] dump_stack+0x84/0xb0
+ [<fffffe0000668678>] panic+0xf4/0x220
+ [<fffffe000018ec78>] free_reserved_area+0x0/0x110
+ [<fffffe000018edd8>] free_pages+0x50/0x88
+ [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
+ [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
+ [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
+ [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
+ [<fffffe00001edc1c>] __fput+0xb0/0x288
+ [<fffffe00001ede4c>] ____fput+0xc/0x14
+ [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
+ [<fffffe0000095c14>] do_notify_resume+0x54/0x58
+
+In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
+on the stage2 pgd which leads to the BUG in put_page_testzero(). This
+happens because a pud_huge() test in unmap_range() returns true when it
+should always be false with 2-level pages tables used by 64k pages.
+This patch removes support for huge puds if 2-level pagetables are
+being used.
+
+Signed-off-by: Mark Salter <msalter@redhat.com>
+[catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/mm/hugetlbpage.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/arm64/mm/hugetlbpage.c
++++ b/arch/arm64/mm/hugetlbpage.c
+@@ -51,7 +51,11 @@ int pmd_huge(pmd_t pmd)
+
+ int pud_huge(pud_t pud)
+ {
++#ifndef __PAGETABLE_PMD_FOLDED
+ return !(pud_val(pud) & PUD_TABLE_BIT);
++#else
++ return 0;
++#endif
+ }
+
+ int pmd_huge_support(void)
--- /dev/null
+From 282cba6b00a95f0277ed71551e3f6b0477e8836b Mon Sep 17 00:00:00 2001
+From: Heiko Stuebner <heiko@sntech.de>
+Date: Fri, 9 May 2014 15:36:57 -0700
+Subject: drivers/rtc/rtc-hym8563.c: set uie_unsupported
+
+From: Heiko Stuebner <heiko@sntech.de>
+
+commit 282cba6b00a95f0277ed71551e3f6b0477e8836b upstream.
+
+The alarm of the hym8563 only supports a minute accuracy, while the uie
+wants an alarm one second in the future. Therefore things like the
+select() syscall will fail with a timeout, because the next alarm will
+happen in a worst case of 60 seconds.
+
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Cc: Alessandro Zummo <a.zummo@towertech.it>
+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>
+
+---
+ drivers/rtc/rtc-hym8563.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/rtc/rtc-hym8563.c
++++ b/drivers/rtc/rtc-hym8563.c
+@@ -569,6 +569,9 @@ static int hym8563_probe(struct i2c_clie
+ if (IS_ERR(hym8563->rtc))
+ return PTR_ERR(hym8563->rtc);
+
++ /* the hym8563 alarm only supports a minute accuracy */
++ hym8563->rtc->uie_unsupported = 1;
++
+ #ifdef CONFIG_COMMON_CLK
+ hym8563_clkout_register_clk(hym8563);
+ #endif
--- /dev/null
+From b985194c8c0a130ed155b71662e39f7eaea4876f Mon Sep 17 00:00:00 2001
+From: Chen Yucong <slaoub@gmail.com>
+Date: Thu, 22 May 2014 11:54:15 -0700
+Subject: hwpoison, hugetlb: lock_page/unlock_page does not match for handling a free hugepage
+
+From: Chen Yucong <slaoub@gmail.com>
+
+commit b985194c8c0a130ed155b71662e39f7eaea4876f upstream.
+
+For handling a free hugepage in memory failure, the race will happen if
+another thread hwpoisoned this hugepage concurrently. So we need to
+check PageHWPoison instead of !PageHWPoison.
+
+If hwpoison_filter(p) returns true or a race happens, then we need to
+unlock_page(hpage).
+
+Signed-off-by: Chen Yucong <slaoub@gmail.com>
+Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Tested-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
+Reviewed-by: Andi Kleen <ak@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/memory-failure.c | 15 ++++++++-------
+ 1 file changed, 8 insertions(+), 7 deletions(-)
+
+--- a/mm/memory-failure.c
++++ b/mm/memory-failure.c
+@@ -1085,15 +1085,16 @@ int memory_failure(unsigned long pfn, in
+ return 0;
+ } else if (PageHuge(hpage)) {
+ /*
+- * Check "just unpoisoned", "filter hit", and
+- * "race with other subpage."
++ * Check "filter hit" and "race with other subpage."
+ */
+ lock_page(hpage);
+- if (!PageHWPoison(hpage)
+- || (hwpoison_filter(p) && TestClearPageHWPoison(p))
+- || (p != hpage && TestSetPageHWPoison(hpage))) {
+- atomic_long_sub(nr_pages, &num_poisoned_pages);
+- return 0;
++ if (PageHWPoison(hpage)) {
++ if ((hwpoison_filter(p) && TestClearPageHWPoison(p))
++ || (p != hpage && TestSetPageHWPoison(hpage))) {
++ atomic_long_sub(nr_pages, &num_poisoned_pages);
++ unlock_page(hpage);
++ return 0;
++ }
+ }
+ set_page_hwpoison_huge_page(hpage);
+ res = dequeue_hwpoisoned_huge_page(hpage);
--- /dev/null
+From dd18dbc2d42af75fffa60c77e0f02220bc329829 Mon Sep 17 00:00:00 2001
+From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
+Date: Fri, 9 May 2014 15:37:00 -0700
+Subject: mm, thp: close race between mremap() and split_huge_page()
+
+From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
+
+commit dd18dbc2d42af75fffa60c77e0f02220bc329829 upstream.
+
+It's critical for split_huge_page() (and migration) to catch and freeze
+all PMDs on rmap walk. It gets tricky if there's concurrent fork() or
+mremap() since usually we copy/move page table entries on dup_mm() or
+move_page_tables() without rmap lock taken. To get it work we rely on
+rmap walk order to not miss any entry. We expect to see destination VMA
+after source one to work correctly.
+
+But after switching rmap implementation to interval tree it's not always
+possible to preserve expected walk order.
+
+It works fine for dup_mm() since new VMA has the same vma_start_pgoff()
+/ vma_last_pgoff() and explicitly insert dst VMA after src one with
+vma_interval_tree_insert_after().
+
+But on move_vma() destination VMA can be merged into adjacent one and as
+result shifted left in interval tree. Fortunately, we can detect the
+situation and prevent race with rmap walk by moving page table entries
+under rmap lock. See commit 38a76013ad80.
+
+Problem is that we miss the lock when we move transhuge PMD. Most
+likely this bug caused the crash[1].
+
+[1] http://thread.gmane.org/gmane.linux.kernel.mm/96473
+
+Fixes: 108d6642ad81 ("mm anon rmap: remove anon_vma_moveto_tail")
+
+Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Rik van Riel <riel@redhat.com>
+Acked-by: Michel Lespinasse <walken@google.com>
+Cc: Dave Jones <davej@redhat.com>
+Cc: David Miller <davem@davemloft.net>
+Acked-by: Johannes Weiner <hannes@cmpxchg.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/mremap.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/mm/mremap.c
++++ b/mm/mremap.c
+@@ -194,10 +194,17 @@ unsigned long move_page_tables(struct vm
+ break;
+ if (pmd_trans_huge(*old_pmd)) {
+ int err = 0;
+- if (extent == HPAGE_PMD_SIZE)
++ if (extent == HPAGE_PMD_SIZE) {
++ VM_BUG_ON(vma->vm_file || !vma->anon_vma);
++ /* See comment in move_ptes() */
++ if (need_rmap_locks)
++ anon_vma_lock_write(vma->anon_vma);
+ err = move_huge_pmd(vma, new_vma, old_addr,
+ new_addr, old_end,
+ old_pmd, new_pmd);
++ if (need_rmap_locks)
++ anon_vma_unlock_write(vma->anon_vma);
++ }
+ if (err > 0) {
+ need_flush = true;
+ continue;
mac80211-fix-nested-rtnl-locking-on-ieee80211_reconfig.patch
mac80211-fix-suspend-vs.-association-race.patch
mac80211-fix-on-channel-remain-on-channel.patch
+mm-thp-close-race-between-mremap-and-split_huge_page.patch
+drivers-rtc-rtc-hym8563.c-set-uie_unsupported.patch
+x86-mm-hugetlb-add-missing-tlb-page-invalidation-for-hugetlb_cow.patch
+arm64-fix-pud_huge-for-2-level-pagetables.patch
+hwpoison-hugetlb-lock_page-unlock_page-does-not-match-for-handling-a-free-hugepage.patch
--- /dev/null
+From 9844f5462392b53824e8b86726e7c33b5ecbb676 Mon Sep 17 00:00:00 2001
+From: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
+Date: Wed, 14 May 2014 11:29:48 +0200
+Subject: x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
+
+From: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
+
+commit 9844f5462392b53824e8b86726e7c33b5ecbb676 upstream.
+
+The invalidation is required in order to maintain proper semantics
+under CoW conditions. In scenarios where a process clones several
+threads, a thread operating on a core whose DTLB entry for a
+particular hugepage has not been invalidated, will be reading from
+the hugepage that belongs to the forked child process, even after
+hugetlb_cow().
+
+The thread will not see the updated page as long as the stale DTLB
+entry remains cached, the thread attempts to write into the page,
+the child process exits, or the thread gets migrated to a different
+processor.
+
+Signed-off-by: Anthony Iliopoulos <anthony.iliopoulos@huawei.com>
+Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corp
+Suggested-by: Shay Goikhman <shay.goikhman@huawei.com>
+Acked-by: Dave Hansen <dave.hansen@intel.com>
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/hugetlb.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/include/asm/hugetlb.h
++++ b/arch/x86/include/asm/hugetlb.h
+@@ -52,6 +52,7 @@ static inline pte_t huge_ptep_get_and_cl
+ static inline void huge_ptep_clear_flush(struct vm_area_struct *vma,
+ unsigned long addr, pte_t *ptep)
+ {
++ ptep_clear_flush(vma, addr, ptep);
+ }
+
+ static inline int huge_pte_none(pte_t pte)
projects / thirdparty / kernel / stable-queue.git / commitdiff
