The patch titled
i386: don't check_pgt_cache in flush_tlb_mm
has been removed from the -mm tree. Its filename was
i386-dont-check_pgt_cache-in-flush_tlb_mm.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
Subject: i386: don't check_pgt_cache in flush_tlb_mm
From: Hugh Dickins <hugh@xxxxxxxxxxx>
No other architecture calls check_pgt_cache() from within flush_tlb_mm(),
and i386 is already calling check_pgt_cache() from the usual places,
tlb_finish_mmu() and cpu_idle() (the latter being odd, but not unusual).
flush_tlb_mm() has no business to be freeing pages: remove that line, which
sneaked in with slub's i386 support.
Signed-off-by: Hugh Dickins <hugh@xxxxxxxxxxx>
Cc: Andi Kleen <ak@xxxxxxx>
Acked-by: Christoph Lameter <clameter@xxxxxxx>
Acked-by: William Lee Irwin III <wli@xxxxxxxxxxxxxx>
Cc: David Miller <davem@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
arch/i386/kernel/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN arch/i386/kernel/smp.c~i386-dont-check_pgt_cache-in-flush_tlb_mm arch/i386/kernel/smp.c
--- a/arch/i386/kernel/smp.c~i386-dont-check_pgt_cache-in-flush_tlb_mm
+++ a/arch/i386/kernel/smp.c
@@ -421,7 +421,7 @@ void flush_tlb_mm (struct mm_struct * mm
}
if (!cpus_empty(cpu_mask))
flush_tlb_others(cpu_mask, mm, TLB_FLUSH_ALL);
- check_pgt_cache();
+
preempt_enable();
}
_
Patches currently in -mm which might be from hugh@xxxxxxxxxxx are
origin.patch
scsi-fix-config_scsi_wait_scan=m.patch
lazy-freeing-of-memory-through-madv_free.patch
restore-madv_dontneed-to-its-original-linux-behaviour.patch
add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated.patch
ext2-reservations.patch
ext2-balloc-use-io_error-label.patch
add-__gfp_movable-for-callers-to-flag-allocations-from-high-memory-that-may-be-migrated-swap-prefetch.patch
prio_tree-debugging-patch.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
