Re: [PATCH] rmap 36 mprotect use vma_merge

[Rajesh Venkatasubramanian]

Hugh,

A couple of small clarifications.

>  void vma_adjust(struct vm_area_struct *vma, unsigned long start,
> -	unsigned long end, pgoff_t pgoff, struct vm_area_struct *next)
> +	unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert)
[snip]
> +	long adjust_next = 0;
> +	int remove_next = 0;
> +
> +	if (next && !insert) {
[snip]
> +			BUG_ON(vma->vm_end != next->vm_start);
> +			adjust_next = end - next->vm_start;
> +		}
> +	}

Can adjust_next overflow?  No? I think making adjust_next in
PAGE_SIZE units will avoid overflow concerns.

[snip]
>  	if (root) {
> +		if (adjust_next) {
> +			vma_prio_tree_init(next);
> +			vma_prio_tree_insert(next, root);
> +		}
>  		vma_prio_tree_init(vma);
>  		vma_prio_tree_insert(vma, root);
>  		flush_dcache_mmap_unlock(mapping);
>  	}

I think this flush_dcache_mmap_unlock should go down - after
__insert_vm_struct call - just before page_table_lock unlock.


> +		__insert_vm_struct(mm, insert);
>  	}
>
>  	spin_unlock(&mm->page_table_lock);
>  	if (mapping)
>  		spin_unlock(&mapping->i_mmap_lock);

Thanks,
Rajesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/