Re: [RFC] memory unplug v5 [1/6] migration by kernel

[Christoph Lameter <clameter@sgi.com>]

On Fri, 15 Jun 2007, KAMEZAWA Hiroyuki wrote:

>  	/*
> -	 * Establish migration ptes or remove ptes
> +	 * This is a corner case handling.
> +	 * When a new swap-ache is read into, it is linked to LRU
> +	 * and treated as swapcache but has no rmap yet.
> +	 * Calling try_to_unmap() against a page->mapping==NULL page is
> +	 * BUG. So handle it here.
> +	 */
> +	if (!page->mapping)
> +		goto unlock;
> +	/*
> +	 * By try_to_unmap(), page->mapcount goes down to 0 here. In this case,
> +	 * we cannot notice that anon_vma is freed while we migrates a pages
> +	 * This rcu_read_lock() delays freeing anon_vma pointer until the end
> +	 * of migration. File cache pages are no problem because of page_lock()
>  	 */
> +	rcu_read_lock();
>  	try_to_unmap(page, 1);

page->mapping needs to be checked after rcu_read_lock. The mapping may be 
removed and the anon_vma dropped after you checked page->mapping.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>