Patch "mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()" has been added to the 3.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()

to the 3.14-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-memory.c-use-entry-access_once-pte-in-handle_pte_fault.patch
and it can be found in the queue-3.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.


>From c0d73261f5c1355a35b8b40e871d31578ce0c044 Mon Sep 17 00:00:00 2001
From: Hugh Dickins <hughd@xxxxxxxxxx>
Date: Wed, 6 Aug 2014 16:05:08 -0700
Subject: mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()

From: Hugh Dickins <hughd@xxxxxxxxxx>

commit c0d73261f5c1355a35b8b40e871d31578ce0c044 upstream.

Use ACCESS_ONCE() in handle_pte_fault() when getting the entry or
orig_pte upon which all subsequent decisions and pte_same() tests will
be made.

I have no evidence that its lack is responsible for the mm/filemap.c:202
BUG_ON(page_mapped(page)) in __delete_from_page_cache() found by
trinity, and I am not optimistic that it will fix it.  But I have found
no other explanation, and ACCESS_ONCE() here will surely not hurt.

If gcc does re-access the pte before passing it down, then that would be
disastrous for correct page fault handling, and certainly could explain
the page_mapped() BUGs seen (concurrent fault causing page to be mapped
in a second time on top of itself: mapcount 2 for a single pte).

Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Sasha Levin <sasha.levin@xxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Cc: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
Cc: Konstantin Khlebnikov <koct9i@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Mel Gorman <mgorman@xxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

---
 mm/memory.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3646,7 +3646,7 @@ static int handle_pte_fault(struct mm_st
 	pte_t entry;
 	spinlock_t *ptl;
 
-	entry = *pte;
+	entry = ACCESS_ONCE(*pte);
 	if (!pte_present(entry)) {
 		if (pte_none(entry)) {
 			if (vma->vm_ops) {


Patches currently in stable-queue which might be from hughd@xxxxxxxxxx are

queue-3.14/mm-page_alloc-use-jump-labels-to-avoid-checking-number_of_cpusets.patch
queue-3.14/mm-non-atomically-mark-page-accessed-during-page-cache-allocation-where-possible.patch
queue-3.14/mm-page_alloc-convert-hot-cold-parameter-and-immediate-callers-to-bool.patch
queue-3.14/mm-page_alloc-only-check-the-zone-id-check-if-pages-are-buddies.patch
queue-3.14/mm-page_alloc-only-check-the-alloc-flags-and-gfp_mask-for-dirty-once.patch
queue-3.14/mm-page_alloc-take-the-alloc_no_watermark-check-out-of-the-fast-path.patch
queue-3.14/fs-buffer-do-not-use-unnecessary-atomic-operations-when-discarding-buffers.patch
queue-3.14/mm-do-not-use-atomic-operations-when-releasing-pages.patch
queue-3.14/mm-page_alloc-reduce-number-of-times-page_to_pfn-is-called.patch
queue-3.14/mm-page_alloc-use-unsigned-int-for-order-in-more-places.patch
queue-3.14/mm-shmem-avoid-atomic-operation-during-shmem_getpage_gfp.patch
queue-3.14/shmem-fix-init_page_accessed-use-to-stop-pagelru-bug.patch
queue-3.14/mm-memory.c-use-entry-access_once-pte-in-handle_pte_fault.patch
queue-3.14/mm-do-not-use-unnecessary-atomic-operations-when-adding-pages-to-the-lru.patch
queue-3.14/include-linux-jump_label.h-expose-the-reference-count.patch
queue-3.14/mm-page_alloc-calculate-classzone_idx-once-from-the.patch
queue-3.14/mm-page_alloc-lookup-pageblock-migratetype-with-irqs-enabled-during-free.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




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]