This is a note to let you know that I've just added the patch titled
mm: numa: do not clear PTE for pte_numa update
to the 3.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-numa-do-not-clear-pte-for-pte_numa-update.patch
and it can be found in the queue-3.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From mgorman@xxxxxxx Tue Jan 7 09:50:13 2014
From: Mel Gorman <mgorman@xxxxxxx>
Date: Tue, 7 Jan 2014 14:00:40 +0000
Subject: mm: numa: do not clear PTE for pte_numa update
To: gregkh@xxxxxxxxxxxxxxxxxxx
Cc: athorlton@xxxxxxx, riel@xxxxxxxxxx, chegu_vinod@xxxxxx, Mel Gorman <mgorman@xxxxxxx>, stable@xxxxxxxxxxxxxxx
Message-ID: <1389103248-17617-6-git-send-email-mgorman@xxxxxxx>
From: Mel Gorman <mgorman@xxxxxxx>
commit 0c5f83c23ca703d32f930393825487257a5cde6d upstream.
The TLB must be flushed if the PTE is updated but change_pte_range is
clearing the PTE while marking PTEs pte_numa without necessarily
flushing the TLB if it reinserts the same entry. Without the flush,
it's conceivable that two processors have different TLBs for the same
virtual address and at the very least it would generate spurious faults.
This patch only unmaps the pages in change_pte_range for a full
protection change.
[riel@xxxxxxxxxx: write pte_numa pte back to the page tables]
Signed-off-by: Mel Gorman <mgorman@xxxxxxx>
Signed-off-by: Rik van Riel <riel@xxxxxxxxxx>
Reviewed-by: Rik van Riel <riel@xxxxxxxxxx>
Cc: Alex Thorlton <athorlton@xxxxxxx>
Cc: Chegu Vinod <chegu_vinod@xxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
mm/mprotect.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -54,13 +54,14 @@ static unsigned long change_pte_range(st
pte_t ptent;
bool updated = false;
- ptent = ptep_modify_prot_start(mm, addr, pte);
if (!prot_numa) {
+ ptent = ptep_modify_prot_start(mm, addr, pte);
ptent = pte_modify(ptent, newprot);
updated = true;
} else {
struct page *page;
+ ptent = *pte;
page = vm_normal_page(vma, addr, oldpte);
if (page) {
int this_nid = page_to_nid(page);
@@ -73,6 +74,7 @@ static unsigned long change_pte_range(st
if (!pte_numa(oldpte) &&
page_mapcount(page) == 1) {
ptent = pte_mknuma(ptent);
+ set_pte_at(mm, addr, pte, ptent);
updated = true;
}
}
@@ -89,7 +91,10 @@ static unsigned long change_pte_range(st
if (updated)
pages++;
- ptep_modify_prot_commit(mm, addr, pte, ptent);
+
+ /* Only !prot_numa always clears the pte */
+ if (!prot_numa)
+ ptep_modify_prot_commit(mm, addr, pte, ptent);
} else if (IS_ENABLED(CONFIG_MIGRATION) && !pte_file(oldpte)) {
swp_entry_t entry = pte_to_swp_entry(oldpte);
Patches currently in stable-queue which might be from mgorman@xxxxxxx are
queue-3.12/sched-numa-skip-inaccessible-vmas.patch
queue-3.12/mm-compaction-respect-ignore_skip_hint-in-update_pageblock_skip.patch
queue-3.12/mm-clear-pmd_numa-before-invalidating.patch
queue-3.12/mm-numa-ensure-anon_vma-is-locked-to-prevent-parallel-thp-splits.patch
queue-3.12/mm-numa-do-not-clear-pte-for-pte_numa-update.patch
queue-3.12/mm-hugetlb-check-for-pte-null-pointer-in-__page_check_address.patch
queue-3.12/mm-numa-serialise-parallel-get_user_page-against-thp-migration.patch
queue-3.12/mm-munlock-fix-deadlock-in-__munlock_pagevec.patch
queue-3.12/mm-numa-avoid-unnecessary-work-on-the-failure-path.patch
queue-3.12/mm-page_alloc-revert-numa-aspect-of-fair-allocation-policy.patch
queue-3.12/mm-mempolicy-correct-putback-method-for-isolate-pages-if-failed.patch
queue-3.12/mm-numa-do-not-clear-pmd-during-pte-update-scan.patch
queue-3.12/mm-numa-call-mmu-notifiers-on-thp-migration.patch
queue-3.12/mm-munlock-fix-a-bug-where-thp-tail-page-is-encountered.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html