Re: VMA_MERGING_FIXUP and patch

[Hugh Dickins]

On Mon, 22 Mar 2004, Andrea Arcangeli wrote:
> 
> what about this?
> 
> @@ -344,6 +360,10 @@ void fastcall page_remove_rmap(struct pa
>    
>   out_unlock:
>  	page_map_unlock(page);
> +
> +	if (page_test_and_clear_dirty(page) && !page_mapped(page))
> +		set_page_dirty(page);
> +
>  	return;
>  }

No, it has to be
	if (!page_mapped(page) && page_test_and_clear_dirty(page))
		set_page_dirty(page);
but the positioning is fine.

> @@ -523,6 +543,11 @@ int fastcall try_to_unmap(struct page * 
>  		dec_page_state(nr_mapped);
>  		ret = SWAP_SUCCESS;
>  	}
> +	page_map_unlock(page);
> +
> +	if (page_test_and_clear_dirty(page) && ret == SWAP_SUCCESS)
> +		set_page_dirty(page);
> +
>  	return ret;
>  }

No, it has to be
	if (ret == SWAP_SUCCESS && page_test_and_clear_dirty(page))
		set_page_dirty(page);

Personally, I'd prefer we leave try_to_unmap with the lock we
had on entry, and do this at the shrink_list end - though I
can see that the way you've done it actually reduces the code.

(The s390 header file comments that the page_test_and_clear_dirty
needs to be done while not mapped, because of race with referenced
bit, and we are opening up to a race now; but unless s390 is very
different, I see nothing wrong with a rare race on referenced -
whereas everything wrong with any race that might lose dirty.)

Excited by that glimpse of find_pte_nonlinear you just gave us;
disappointed to find it empty ;-)

Hugh

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