linux-toradex.git/mm/migrate.c, branch v3.14.23

mm: migrate: Close race between migration completion and mprotect

2014-10-09T19:21:26+00:00

commit d3cb8bf6081b8b7a2dabb1264fe968fd870fa595 upstream.

A migration entry is marked as write if pte_write was true at the time the
entry was created. The VMA protections are not double checked when migration
entries are being removed as mprotect marks write-migration-entries as
read. It means that potentially we take a spurious fault to mark PTEs write
again but it's straight-forward. However, there is a race between write
migrations being marked read and migrations finishing. This potentially
allows a PTE to be write that should have been read. Close this race by
double checking the VMA permissions using maybe_mkwrite when migration
completes.

[torvalds@linux-foundation.org: use maybe_mkwrite]
Signed-off-by: Mel Gorman 
Acked-by: Rik van Riel 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: fix swapops.h:131 bug if remap_file_pages raced migration

2014-03-21T05:09:09+00:00

Add remove_linear_migration_ptes_from_nonlinear(), to fix an interesting
little include/linux/swapops.h:131 BUG_ON(!PageLocked) found by trinity:
indicating that remove_migration_ptes() failed to find one of the
migration entries that was temporarily inserted.

The problem comes from remap_file_pages()'s switch from vma_interval_tree
(good for inserting the migration entry) to i_mmap_nonlinear list (no good
for locating it again); but can only be a problem if the remap_file_pages()
range does not cover the whole of the vma (zap_pte() clears the range).

remove_migration_ptes() needs a file_nonlinear method to go down the
i_mmap_nonlinear list, applying linear location to look for migration
entries in those vmas too, just in case there was this race.

The file_nonlinear method does need rmap_walk_control.arg to do this;
but it never needed vma passed in - vma comes from its own iteration.

Reported-and-tested-by: Dave Jones 
Reported-and-tested-by: Sasha Levin 
Signed-off-by: Hugh Dickins 
Signed-off-by: Linus Torvalds

mm: fix GFP_THISNODE callers and clarify

2014-03-11T00:26:19+00:00

GFP_THISNODE is for callers that implement their own clever fallback to
remote nodes.  It restricts the allocation to the specified node and
does not invoke reclaim, assuming that the caller will take care of it
when the fallback fails, e.g.  through a subsequent allocation request
without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback or
triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too, but
at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.

Signed-off-by: Johannes Weiner 
Acked-by: Rik van Riel 
Cc: Jan Stancek 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migrate.c: fix setting of cpupid on page migration twice against normal page

2014-01-28T05:02:40+00:00

Commit 7851a45cd3f6 ("mm: numa: Copy cpupid on page migration") copies
over the cpupid at page migration time.  It is unnecessary to set it
again in alloc_misplaced_dst_page().

Signed-off-by: Wanpeng Li 
Reviewed-by: Naoya Horiguchi 
Acked-by: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

sched/numa: fix setting of cpupid on page migration twice

2014-01-24T00:36:52+00:00

Commit 7851a45cd3f6 ("mm: numa: Copy cpupid on page migration") copiess
over the cpupid at page migration time.  It is unnecessary to set it
again in migrate_misplaced_transhuge_page().

Signed-off-by: Wanpeng Li 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Naoya Horiguchi 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: dump page when hitting a VM_BUG_ON using VM_BUG_ON_PAGE

2014-01-24T00:36:50+00:00

Most of the VM_BUG_ON assertions are performed on a page.  Usually, when
one of these assertions fails we'll get a BUG_ON with a call stack and
the registers.

I've recently noticed based on the requests to add a small piece of code
that dumps the page to various VM_BUG_ON sites that the page dump is
quite useful to people debugging issues in mm.

This patch adds a VM_BUG_ON_PAGE(cond, page) which beyond doing what
VM_BUG_ON() does, also dumps the page before executing the actual
BUG_ON.

[akpm@linux-foundation.org: fix up includes]
Signed-off-by: Sasha Levin 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migrate: remove unused function, fail_migrate_page()

2014-01-22T00:19:49+00:00

fail_migrate_page() isn't used anywhere, so remove it.

Signed-off-by: Joonsoo Kim 
Acked-by: Christoph Lameter 
Reviewed-by: Naoya Horiguchi 
Reviewed-by: Wanpeng Li 
Cc: Rafael Aquini 
Cc: Vlastimil Babka 
Cc: Wanpeng Li 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Zhang Yanfei 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migrate: remove putback_lru_pages, fix comment on putback_movable_pages

2014-01-22T00:19:49+00:00

Some part of putback_lru_pages() and putback_movable_pages() is
duplicated, so it could confuse us what we should use.  We can remove
putback_lru_pages() since it is not really needed now.  This makes us
undestand and maintain the code more easily.

And comment on putback_movable_pages() is stale now, so fix it.

Signed-off-by: Joonsoo Kim 
Reviewed-by: Wanpeng Li 
Cc: Christoph Lameter 
Cc: Naoya Horiguchi 
Cc: Rafael Aquini 
Cc: Vlastimil Babka 
Cc: Wanpeng Li 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Zhang Yanfei 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migrate: correct failure handling if !hugepage_migration_support()

2014-01-22T00:19:49+00:00

We should remove the page from the list if we fail with ENOSYS, since
migrate_pages() consider error cases except -ENOMEM and -EAGAIN as
permanent failure and it assumes that the page would be removed from the
list.  Without this patch, we could overcount number of failure.

In addition, we should put back the new hugepage if
!hugepage_migration_support().  If not, we would leak hugepage memory.

Signed-off-by: Joonsoo Kim 
Acked-by: Christoph Lameter 
Reviewed-by: Wanpeng Li 
Reviewed-by: Naoya Horiguchi 
Cc: Rafael Aquini 
Cc: Vlastimil Babka 
Cc: Wanpeng Li 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Zhang Yanfei 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migrate: add comment about permanent failure path

2014-01-22T00:19:49+00:00

Let's add a comment about where the failed page goes to, which makes
code more readable.

Signed-off-by: Naoya Horiguchi 
Signed-off-by: Joonsoo Kim 
Acked-by: Christoph Lameter 
Reviewed-by: Wanpeng Li 
Acked-by: Rafael Aquini 
Cc: Vlastimil Babka 
Cc: Wanpeng Li 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Vlastimil Babka 
Cc: Zhang Yanfei 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds