diff options
| author | Andrea Arcangeli <aarcange@redhat.com> | 2011-01-13 15:47:08 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-01-13 17:32:45 -0800 |
| commit | 94fcc585fb85ad7b059c70872489b50044d401f3 (patch) | |
| tree | 67efce3803149bec77df1f50a06f384deae02ba6 /mm/mmap.c | |
| parent | bc835011afbea3957217ee716093d791fb2fe44f (diff) | |
| download | talos-op-linux-94fcc585fb85ad7b059c70872489b50044d401f3.tar.gz talos-op-linux-94fcc585fb85ad7b059c70872489b50044d401f3.zip | |
thp: avoid breaking huge pmd invariants in case of vma_adjust failures
An huge pmd can only be mapped if the corresponding 2M virtual range is
fully contained in the vma. At times the VM calls split_vma twice, if the
first split_vma succeeds and the second fail, the first split_vma remains
in effect and it's not rolled back. For split_vma or vma_adjust to fail
an allocation failure is needed so it's a very unlikely event (the out of
memory killer would normally fire before any allocation failure is visible
to kernel and userland and if an out of memory condition happens it's
unlikely to happen exactly here). Nevertheless it's safer to ensure that
no huge pmd can be left around if the vma is adjusted in a way that can't
fit hugepages anymore at the new vm_start/vm_end address.
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm/mmap.c')
| -rw-r--r-- | mm/mmap.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/mm/mmap.c b/mm/mmap.c index 753f44d17047..73cc648873d6 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -589,6 +589,8 @@ again: remove_next = 1 + (end > next->vm_end); } } + vma_adjust_trans_huge(vma, start, end, adjust_next); + /* * When changing only vma->vm_end, we don't really need anon_vma * lock. This is a fairly rare case by itself, but the anon_vma |
