Prev: [PATCH] Staging: tm6000: fix coding style issues of tm6000-cards.c
Next: [PATCH 2/3] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information
From: Mel Gorman on 27 Apr 2010 17:40
After V1, it was clear that execve was still racing but eventually died
in an exec-related race. An additional part of the test was created that
hammers exec() to reproduce typically within 10 minutes rather than several
hours. The problem was that the VMA is moved under lock but not the page
tables. Migration fails to remove the migration PTE from its new location and
a BUG is later triggered. The third patch in this series is a candidate fix.

Changelog since V1
o Handle the execve race
o Be sure that rmap_walk() releases the correct VMA lock
o Hold the anon_vma lock for the address lookup and the page remap
o Add reviewed-bys

There are a number of races between migration and other operations that mean a
migration PTE can be left behind. Broadly speaking, migration works by locking
a page, unmapping it, putting a migration PTE in place that looks like a swap
entry, copying the page and remapping the page removing the old migration PTE.
If a fault occurs, the faulting process waits until migration completes.

The problem is that there are some races that either allow migration PTEs to
be copied or a migration PTE to be left behind. Migration still completes and
the page is unlocked but later a fault will call migration_entry_to_page()
and BUG() because the page is not locked. This series aims to close some
of these races.

Patch 1 alters fork() to restart page table copying when a migration PTE is
encountered.

Patch 2 has vma_adjust() acquire the anon_vma lock and makes rmap_walk()
aware that VMAs on the chain may have different anon_vma locks that
also need to be acquired.

Patch 3 notes that while a VMA is moved under the anon_vma lock, the page
tables are not similarly protected. Where migration PTEs are
encountered, they are cleaned up.

The reproduction case was as follows;

1. Run kernel compilation in a loop
2. Start three processes, each of which creates one mapping. The three stress
different aspects of the problem. The operations they undertake are;
a) Forks a hundred children, each of which faults the mapping
Purpose: stress tests migration pte removal
b) Forks a hundred children, each which punches a hole in the mapping
and faults what remains
Purpose: stress test VMA manipulations during migration
c) Forks a hundren children, each of which execs and calls echo
Purpose: stress test the execve race
3. Constantly compact memory using /proc/sys/vm/compact_memory so migration
is active all the time. In theory, you could also force this using
sys_move_pages or memory hot-remove but it'd be nowhere near as easy
to test.

At the time of sending, it has been running several hours without problems
with a workload that would fail within a few minutes without the patches.

include/linux/migrate.h | 7 +++++++
mm/ksm.c | 22 ++++++++++++++++++++--
mm/memory.c | 25 +++++++++++++++----------
mm/migrate.c | 2 +-
mm/mmap.c | 6 ++++++
mm/mremap.c | 29 +++++++++++++++++++++++++++++
mm/rmap.c | 28 +++++++++++++++++++++++-----
7 files changed, 101 insertions(+), 18 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH] Staging: tm6000: fix coding style issues of tm6000-cards.c
Next: [PATCH 2/3] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information