Re: [PATCH resend] rmap: recompute pgoff for unmapping huge page

[Andrew Morton]

On Mon, 4 Mar 2013 20:47:31 +0800 Hillf Danton <dhillf@xxxxxxxxx> wrote:

> [Resend due to error in delivering to linux-kernel@xxxxxxxxxxxxxxx,
> caused probably by the rich format provided by the mail agent by default.]
> 
> We have to recompute pgoff if the given page is huge, since result based on
> HPAGE_SIZE is not approapriate for scanning the vma interval tree, as shown
> by commit 36e4f20af833(hugetlb: do not use vma_hugecache_offset() for
> vma_prio_tree_foreach)
> 
> ...
>
> @@ -1513,6 +1513,9 @@ static int try_to_unmap_file(struct page
>  	unsigned long max_nl_size = 0;
>  	unsigned int mapcount;
> 
> +	if (PageHuge(page))
> +		pgoff = page->index << compound_order(page);
> +
>  	mutex_lock(&mapping->i_mmap_mutex);
>  	vma_interval_tree_foreach(vma, &mapping->i_mmap, pgoff, pgoff) {
>  		unsigned long address = vma_address(page, vma);

Also, what does this patch actually do?

I have a canned response nowadays:

When writing a changelog, please describe the end-user-visible effects
of that bug, so that others can more easily decide which kernel
version(s) should be fixed, and so that downstream kernel maintainers
can more easily work out whether this patch will fix a problem which
they or their customers are observing.

--
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/