Hi Eric,
On Sun, Sep 26, 2010 at 2:34 AM, Eric W. Biederman
<ebiederm@xxxxxxxxxxxx> wrote:
> Consolidate vma destruction in remove_vma. This is slightly
> better for code size and for code maintenance. Avoiding the pain
> of 3 copies of everything needed to tear down a vma.
>
> Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxxxxxxxx>
> ---
> mm/mmap.c | 21 +++++----------------
> 1 files changed, 5 insertions(+), 16 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 6128dc8..17dd003 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -643,16 +643,10 @@ again: remove_next = 1 + (end > next->vm_end);
> spin_unlock(&mapping->i_mmap_lock);
>
> if (remove_next) {
> - if (file) {
> - fput(file);
> - if (next->vm_flags & VM_EXECUTABLE)
> - removed_exe_file_vma(mm);
> - }
> if (next->anon_vma)
> anon_vma_merge(vma, next);
> + remove_vma(next);
remove_vma() does vma->vm_ops->close() but we don't do that here. Are
you sure the conversion is safe?
> mm->map_count--;
> - mpol_put(vma_policy(next));
> - kmem_cache_free(vm_area_cachep, next);
> /*
> * In mprotect's case 6 (see comments on vma_merge),
> * we must remove another next too. It would clutter
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href