On Wed, Apr 15, 2009 at 05:05:54PM +0900, KOSAKI Motohiro wrote:
> - /*
> - * If the page is mlock()d, we cannot swap it out.
> - * If it's recently referenced (perhaps page_referenced
> - * skipped over this mm) then we should reactivate it.
> - */
> if (!migration) {
> + if (PageSwapCache(page) &&
> + page_count(page) != page_mapcount(page) + 2) {
> + ret = SWAP_FAIL;
> + goto out_unmap;
> + }
> +
> + /*
> + * If the page is mlock()d, we cannot swap it out.
> + * If it's recently referenced (perhaps page_referenced
> + * skipped over this mm) then we should reactivate it.
> + */
> if (vma->vm_flags & VM_LOCKED) {
> ret = SWAP_MLOCK;
> goto out_unmap;
> @@ -790,7 +796,19 @@ static int try_to_unmap_one(struct page
>
> /* Nuke the page table entry. */
> flush_cache_page(vma, address, page_to_pfn(page));
> - pteval = ptep_clear_flush_notify(vma, address, pte);
> + pteval = ptep_clear_flush(vma, address, pte);
> +
> + if (!migration) {
> + /* re-check */
> + if (PageSwapCache(page) &&
> + page_count(page) != page_mapcount(page) + 2) {
> + /* We lose race against get_user_pages_fast() */
> + set_pte_at(mm, address, pte, pteval);
> + ret = SWAP_FAIL;
> + goto out_unmap;
> + }
> + }
> + mmu_notifier_invalidate_page(vma->vm_mm, address);
With regard to mmu notifier, this is the opposite of the right
ordering. One mmu_notifier_invalidate_page must run _before_ the first
check. The ptep_clear_flush_notify will then stay and there's no need
of a further mmu_notifier_invalidate_page after the second check.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
