linux.git/mm/migrate.c, branch v2.6.38

mm: grab rcu read lock in move_pages()

2011-02-25T23:07:36+00:00

The move_pages() usage of find_task_by_vpid() requires rcu_read_lock() to
prevent free_pid() from reclaiming the pid.

Without this patch, RCU warnings are printed in v2.6.38-rc4 move_pages()
with:

  CONFIG_LOCKUP_DETECTOR=y
  CONFIG_PREEMPT=y
  CONFIG_LOCKDEP=y
  CONFIG_PROVE_LOCKING=y
  CONFIG_PROVE_RCU=y

Previously, migrate_pages() went through a similar transformation
replacing usage of tasklist_lock with rcu read lock:

  commit 55cfaa3cbdd29c4919ecb5fb8965c310f357e48c
  Author: Zeng Zhaoming 
  Date:   Thu Dec 2 14:31:13 2010 -0800

      mm/mempolicy.c: add rcu read lock to protect pid structure

  commit 1e50df39f6e2c3a4a3394df62baa8a213df16c54
  Author: KOSAKI Motohiro 
  Date:   Thu Jan 13 15:46:14 2011 -0800

      mempolicy: remove tasklist_lock from migrate_pages

Signed-off-by: Greg Thelen 
Cc: Mel Gorman 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: KAMEZAWA Hiroyuki 
Cc: "Paul E. McKenney" 
Cc: Tetsuo Handa 
Cc: Sergey Senozhatsky 
Cc: Oleg Nesterov 
Cc: Zeng Zhaoming 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm/migration: fix page corruption during hugepage migration

2011-02-03T00:03:18+00:00

If migrate_huge_page by memory-failure fails , it calls put_page in itself
to decrease page reference and caller of migrate_huge_page also calls
putback_lru_pages.  It can do double free of page so it can make page
corruption on page holder.

In addtion, clean of pages on caller is consistent behavior with
migrate_pages by cf608ac19c ("mm: compaction: fix COMPACTPAGEFAILED
counting").

Signed-off-by: Minchan Kim 
Cc: Andrea Arcangeli 
Cc: Christoph Lameter 
Cc: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: when migrate_pages returns 0, all pages must have been released

2011-02-03T00:03:18+00:00

In some cases migrate_pages could return zero while still leaving a few
pages in the pagelist (and some caller wouldn't notice it has to call
putback_lru_pages after commit cf608ac19c9 ("mm: compaction: fix
COMPACTPAGEFAILED counting")).

Add one missing putback_lru_pages not added by commit cf608ac19c95 ("mm:
compaction: fix COMPACTPAGEFAILED counting").

Signed-off-by: Andrea Arcangeli 
Signed-off-by: Minchan Kim 
Reviewed-by: Minchan Kim 
Cc: Christoph Lameter 
Acked-by: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: migration: clarify migrate_pages() comment

2011-01-26T00:50:02+00:00

Callers of migrate_pages should putback_lru_pages to return pages
isolated to LRU or free list.  Now comment is rather confusing.  It says
caller always have to call it.

It is more clear to point out that the caller has to call it if
migrate_pages's return value isn't zero.

Signed-off-by: Minchan Kim 
Cc: Christoph Lameter 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

memcg: fix memory migration of shmem swapcache

2011-01-14T01:32:51+00:00

In the current implementation mem_cgroup_end_migration() decides whether
the page migration has succeeded or not by checking "oldpage->mapping".

But if we are tring to migrate a shmem swapcache, the page->mapping of it
is NULL from the begining, so the check would be invalid.  As a result,
mem_cgroup_end_migration() assumes the migration has succeeded even if
it's not, so "newpage" would be freed while it's not uncharged.

This patch fixes it by passing mem_cgroup_end_migration() the result of
the page migration.

Signed-off-by: Daisuke Nishimura 
Reviewed-by: Minchan Kim 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: Balbir Singh 
Cc: Minchan Kim 
Reviewed-by: Johannes Weiner 
Cc: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: fix hugepage migration

2011-01-14T01:32:49+00:00

2.6.37 added an unmap_and_move_huge_page() for memory failure recovery,
but its anon_vma handling was still based around the 2.6.35 conventions.
Update it to use page_lock_anon_vma, get_anon_vma, page_unlock_anon_vma,
drop_anon_vma in the same way as we're now changing unmap_and_move().

I don't particularly like to propose this for stable when I've not seen
its problems in practice nor tested the solution: but it's clearly out of
synch at present.

Signed-off-by: Hugh Dickins 
Cc: Mel Gorman 
Cc: Rik van Riel 
Cc: Naoya Horiguchi 
Cc: "Jun'ichi Nomura" 
Cc: Andi Kleen 
Cc:  [2.6.37, 2.6.36]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: fix migration hangs on anon_vma lock

2011-01-14T01:32:49+00:00

Increased usage of page migration in mmotm reveals that the anon_vma
locking in unmap_and_move() has been deficient since 2.6.36 (or even
earlier).  Review at the time of f18194275c39835cb84563500995e0d503a32d9a
("mm: fix hang on anon_vma->root->lock") missed the issue here: the
anon_vma to which we get a reference may already have been freed back to
its slab (it is in use when we check page_mapped, but that can change),
and so its anon_vma->root may be switched at any moment by reuse in
anon_vma_prepare.

Perhaps we could fix that with a get_anon_vma_unless_zero(), but let's
not: just rely on page_lock_anon_vma() to do all the hard thinking for us,
then we don't need any rcu read locking over here.

In removing the rcu_unlock label: since PageAnon is a bit in
page->mapping, it's impossible for a !page->mapping page to be anon; but
insert VM_BUG_ON in case the implementation ever changes.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Hugh Dickins 
Reviewed-by: Mel Gorman 
Reviewed-by: Rik van Riel 
Cc: Naoya Horiguchi 
Cc: "Jun'ichi Nomura" 
Cc: Andi Kleen 
Cc:  [2.6.37, 2.6.36]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: migration: use rcu_dereference_protected when dereferencing the radix tree slot during file page migration

2011-01-14T01:32:48+00:00

migrate_pages() -> unmap_and_move() only calls rcu_read_lock() for
anonymous pages, as introduced by git commit
989f89c57e6361e7d16fbd9572b5da7d313b073d ("fix rcu_read_lock() in page
migraton").  The point of the RCU protection there is part of getting a
stable reference to anon_vma and is only held for anon pages as file pages
are locked which is sufficient protection against freeing.

However, while a file page's mapping is being migrated, the radix tree is
double checked to ensure it is the expected page.  This uses
radix_tree_deref_slot() -> rcu_dereference() without the RCU lock held
triggering the following warning.

[  173.674290] ===================================================
[  173.676016] [ INFO: suspicious rcu_dereference_check() usage. ]
[  173.676016] ---------------------------------------------------
[  173.676016] include/linux/radix-tree.h:145 invoked rcu_dereference_check() without protection!
[  173.676016]
[  173.676016] other info that might help us debug this:
[  173.676016]
[  173.676016]
[  173.676016] rcu_scheduler_active = 1, debug_locks = 0
[  173.676016] 1 lock held by hugeadm/2899:
[  173.676016]  #0:  (&(&inode->i_data.tree_lock)->rlock){..-.-.}, at: [] migrate_page_move_mapping+0x40/0x1ab
[  173.676016]
[  173.676016] stack backtrace:
[  173.676016] Pid: 2899, comm: hugeadm Not tainted 2.6.37-rc5-autobuild
[  173.676016] Call Trace:
[  173.676016]  [] ? printk+0x14/0x1b
[  173.676016]  [] lockdep_rcu_dereference+0x7d/0x86
[  173.676016]  [] migrate_page_move_mapping+0xca/0x1ab
[  173.676016]  [] migrate_page+0x23/0x39
[  173.676016]  [] buffer_migrate_page+0x22/0x107
[  173.676016]  [] ? buffer_migrate_page+0x0/0x107
[  173.676016]  [] move_to_new_page+0x9a/0x1ae
[  173.676016]  [] migrate_pages+0x1e7/0x2fa

This patch introduces radix_tree_deref_slot_protected() which calls
rcu_dereference_protected().  Users of it must pass in the
mapping->tree_lock that is protecting this dereference.  Holding the tree
lock protects against parallel updaters of the radix tree meaning that
rcu_dereference_protected is allowable.

[akpm@linux-foundation.org: remove unneeded casts]
Signed-off-by: Mel Gorman 
Cc: Minchan Kim 
Cc: KAMEZAWA Hiroyuki 
Cc: Milton Miller 
Cc: Nick Piggin 
Cc: Wu Fengguang 
Cc: 		[2.6.37.early]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

thp: pmd_trans_huge migrate bugcheck

2011-01-14T01:32:42+00:00

No pmd_trans_huge should ever materialize in migration ptes areas, because
we split the hugepage before migration ptes are instantiated.

Signed-off-by: Andrea Arcangeli 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: migration: cleanup migrate_pages API by matching types for offlining and sync

2011-01-14T01:32:34+00:00

With the introduction of the boolean sync parameter, the API looks a
little inconsistent as offlining is still an int.  Convert offlining to a
bool for the sake of being tidy.

Signed-off-by: Mel Gorman 
Cc: Andrea Arcangeli 
Cc: KOSAKI Motohiro 
Cc: Rik van Riel 
Acked-by: Johannes Weiner 
Cc: Andy Whitcroft 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds